git: kernel - Remove proc_token, replace proc, pgrp, and session structure backend
Matthew Dillon
dillon at crater.dragonflybsd.org
Thu Oct 24 22:06:02 PDT 2013
commit b22b6ecd66ef2104abc07ae243f04125b30aa38d
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date: Thu Oct 24 21:54:48 2013 -0700
kernel - Remove proc_token, replace proc, pgrp, and session structure backend
* Isolate the remaining exposed topology for proc, pgrp, and session
into one source file (kern_proc.c).
* Remove allproc, zombproc, pgrp's spinlocks, and start tracking session
structures so we don't have to indirect through other system structures.
* Replace with arrays-of-lists, 1024 elements, including a 1024 element
token lock array to protect each list.
proc_tokens[1024]
allprocs[1024]
allpgrps[1024]
allsessn[1024]
This removes nearly all the prior proc_token contention and also removes
process-group processing contention and makes it easier to track tty
sessions.
* Normal process, Zombie processes, the original linear list, and the
original has mechanic are now all combined into a single allprocs[]
table. The various API functions will filter out zombie vs non-zombie
based on the type of request.
* Rewrite the PID allocator to take advantage of the hashed array topology.
An atomic_fetchadd_int() is used on the static base value which will cause
each cpu to start at a different array entry, thus removing SMP conflicts.
At the moment we iterate the relatively small number of elements in the
bucket to find a free pid.
Since the same proc_tokens[n] lock applies to all three arrays (proc,
pgrp, and session), we can validate the pid against all three at the
same time with a single lock.
* Rewrite the procs sysctl to iterate the hash table. Since there are
1024 different locks, a 'ps' or similar operation no longer has any
significant effect on system performance, and 'ps' is VERY fast now
regardless of the load.
* poudriere bulk build tests on a blade (4 core / 8 thread) shows virtually
no SMP collisions even under extreme loads.
* poudriere bulk build tests on monster (48-core opteron) show very low
SMP collision statistics outside of filesystem writes in most situations.
Pipes (which are already fine-grained) sometimes show significant
collisions.
Most importantly, NO collisions on the process fork/exec/exit critical
path, end-to-end. Not even in the VM system.
Summary of changes:
sys/kern/init_main.c | 3 +-
sys/kern/kern_proc.c | 587 +++++++++++++++++++++++++++++----------------------
sys/sys/proc.h | 23 +-
3 files changed, 347 insertions(+), 266 deletions(-)
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/b22b6ecd66ef2104abc07ae243f04125b30aa38d
--
DragonFly BSD source repository
More information about the Commits
mailing list