Messages in this thread | | | Subject | Re: sem.c multithreading | From | Christoph Rohland <> | Date | 02 Nov 1999 10:41:46 +0100 |
| |
Hi Manfred,
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/
| |