Manfred Spraul <manfreds@colorfullife.com> writes:
> 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.
Yes, you are right. I checked myself a little more and your approach
is faster and more simple.
> > 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
SEMMNI is way to small for big applications. Many databases (e.g. IBM
DB/2) use semaphores to administer clients. So you run out of
semaphores if you connect many clients to the databases
As I said I am working on making SEMMNI, SEMMSL and SEMMNS
sysctlable. This leads to allocating the array via kmalloc and also
possibly having a really big array.
Greetings
Christoph
-
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/