Re: sem.c multithreading

Manfred Spraul (manfreds@colorfullife.com)
Mon, 01 Nov 1999 15:55:08 +0100

Christoph Rohland wrote:
>
> Hi Manfred,
>
> I just got the 2.3.25 prepatch with your semaphore changes. That's a
> great enhancement, but wouldn't it be better to include the per
> semaphore lock into the semaphore structure instead of preallocating
> it in the administration array?
>

My design has one advantage: I need no global spinlocks, all spinlocks
are per-semaphore array.
The 'shortest path' for 'acquire a free semaphore' needs just one
spin_lock and one spin_unlock().
There is a global semaphore, but you need it only for array removal and
creation.

> I am just working on making the shm and sem limits sysctl'able. Here I
> run into many inherent problems with these fixed size arrays:
>
> You lock a lot of memory (and your patch doubles this locked memory)
> If you kmalloc this you run into problems with high limits...
>
Which kmalloc() are you talking about? The spinlocks are allocated at
compile time, there is no kmalloc(). There is one spinlock per array,
not one spinlock per semaphore.

And which limit are you talking about?
* SEMMNI: (the number of semaphore arrays) currently 128. Is that really
a problem? With my patch, this means that 1Kb memory, allocated at
compile time. If you make this number

* SEMOPM: <~ 160
* SEMMSL: < 512.
I think these 2 limits are problematic, but the first problem is the
stack usage, not kmalloc.

* SEMVMX: 32767. Should be ok.

all other limits are unused

--
	Manfred


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/