kernel - Remove proc_token, replace proc, pgrp, and session structure backend
authorMatthew Dillon <dillon@apollo.backplane.com>
Fri, 25 Oct 2013 04:54:48 +0000 (21:54 -0700)
committerMatthew Dillon <dillon@apollo.backplane.com>
Fri, 25 Oct 2013 04:54:48 +0000 (21:54 -0700)
commitb22b6ecd66ef2104abc07ae243f04125b30aa38d
tree9d982681dfb7d285237096cdf4a0dafdebfc92e6
parenta8d3ab5322237ab812bfdf95c32e45fff302f339
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.
sys/kern/init_main.c
sys/kern/kern_proc.c
sys/sys/proc.h