Louis,
On 09/16/10 10:46, Louis Munro wrote:
Hi,
I'm trying to understand the relationship between semaphores,
semaphore sets and the relevant resource controls in solaris 10.
My current understanding is that the total number of semaphores
available to a project is the product of project.max-sem-ids *
process.max-sem-nsems (number of sets * number of semaphores per
set). Is that correct?
There is no limit on the number of semaphores available to a
project. Just a limit on the number of semaphore ids.
In theory max-sem-ids * max-sem-nsems forms an upper bound, but
different processes in a project could have different
process.max-sem-nsems settings (as it is a process rctl). A more
conservative upper bound is max-sem-ids * 32K (32K is the inviolable
limit on the number of semaphores per set, imposed by the semop
interface).
I also understand that when a set is full a request for an aditional
semaphore will be allocated form another set if there is one
available. Again, is that right?
Not at all. The system doesn't keep semaphore sets lying around,
they are created when you allocate them. process.max-sem-nsems just
limits their size.
Once upon a time, sets were allocated from a single large pool. That
was unnecessary, and placed confusing, hard to observe limits on
allocation (e.g. fragmentation of the semaphore pool could result in
allocation failures even though sufficient semaphores were
available). When we replaced the tunables with the resource
controls, we ripped that mechanism out entirely.
Now the logic is simple:
semget(nsems):
if project's semids >= max-sem-ids:
fail
if nsems > max-sem-nsems:
fail
project's semids += 1
dynamically allocate semaphores
Last, if that is the case, why do we have sets to begin with?
Why not use a single big pool of semaphores?
There must be some use to the sets or else I don't see why they would
still be around but I can't figure out a case where a large number of
small sets would be better than a small number of large sets. Does
anyone know?
See http://hub.opensolaris.org/bin/view/Project+rm/sysv for more
information on the resource controls and the rationale behind the
changes.
As others have pointed out, the purpose of semaphore sets was to let
you perform multiple operations on a single semaphore set
atomically. I think the number of people who truly need that these
days is small. But the functionality is popular because it lets
people perform many semaphore operations with a single system call.
Should you use large sets or small sets? It's a trade-off.
A large number of small sets scale better if you have a lot of
independent operations, but bulk operations will require more system
calls and you will be limited in what you can do atomically.
A small number of large sets can be a serious bottleneck if you have
a lot of independent operations, but will let you perform large,
aggregate operations for atomicity or performance.
Dave
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
