kernel - Implementat much deeper use of shared VM object locks
authorMatthew Dillon <dillon@apollo.backplane.com>
Sat, 23 Feb 2013 19:22:00 +0000 (11:22 -0800)
committerMatthew Dillon <dillon@apollo.backplane.com>
Sat, 23 Feb 2013 19:22:00 +0000 (11:22 -0800)
commitce94514e6b38abad5c78107e3d1ac401117df5c4
tree0e6b871b9191fd6634c0f41549f5a601d68c5a85
parent1b3342693b737646f3cab0715e31ec6ab5216b38
kernel - Implementat much deeper use of shared VM object locks

* Use a shared VM object lock on terminal (and likely highly shared)
  OBJT_VNODE objects.  For example, binaries in the system such as
  /bin/sh or /usr/bin/make.

  This greatly improves fork/exec and related VM faults on concurrently
  executing binaries.  Most commonly, parallel builds often exec
  hundreds of thousands of sh's and make's.

  +50% to +100% nominal improved performance under these conditions.
  +200% to +300% improved poudriere performance during the depend
  stage.

* Formalize the shared VM object lock with a new API function,
  vm_object_lock_maybe_shared(), which determines whether a VM
  object meets the requirements for obtaining a shared lock.

* Adjust the vm_fault*() APIs to track whether the VM object is
  locked shared or exclusive on entry.

* Clarify that OBJ_ONEMAPPING is only applicable to OBJT_DEFAULT
  and OBJT_SWAP objects.

* Heavy work on the exec path.  Somewhat lighter work on the exit
  path.  Tons more work could be done.
sys/kern/imgact_aout.c
sys/kern/imgact_elf.c
sys/kern/lwkt_token.c
sys/vm/swap_pager.c
sys/vm/vm_fault.c
sys/vm/vm_map.c
sys/vm/vm_map.h
sys/vm/vm_object.c
sys/vm/vm_object.h
sys/vm/vm_page.c
sys/vm/vnode_pager.c