cvs commit: src/sys/i386/i386 pmap.c src/sys/i386/include pmap.h

[Peter Wemm]

peter       2006-04-26 21:49:20 UTC

  FreeBSD src repository

  Modified files:
    sys/i386/i386        pmap.c 
    sys/i386/include     pmap.h 
  Log:
  MFamd64: shrink pv entries from 24 bytes to about 12 bytes. (336 pv entries
  per page = effectively 12.19 bytes per pv entry after overheads).
  Instead of using a shared UMA zone for 24 byte pv entries (two 8-byte tailq
  nodes, a 4 byte pointer, and a 4 byte address), we allocate a page at a
  time per process.  This provides 336 pv entries per process (actually, per
  pmap address space) and eliminates one of the 8-byte tailq entries since
  we now can track per-process pv entries implicitly.  The pointer to
  the pmap can be eliminated by doing address arithmetic to find the metadata
  on the page headers to find a single pointer shared by all 336 entries.
  There is an 11-int bitmap for the freelist of those 336 entries.
  
  This is mostly a mechanical conversion from amd64, except:
  * i386 has to allocate kvm and map the pages, amd64 has them outside of kvm
  * native word size is smaller, so bitmaps etc become 32 bit instead of 64
  * no dump_add_page() etc stuff because they are in kvm always.
  * various pmap internals tweaks because pmap uses direct map on amd64 but
    on i386 it has to use sched_pin and temporary mappings.
  
  Also, sysctl vm.pmap.pv_entry_max and vm.pmap.shpgperproc are now
  dynamic sysctls.  Like on amd64, i386 can now tune the pv entry limits
  without a recompile or reboot.
  
  This is important because of the following scenario.   If you have a 1GB
  file (262144 pages) mmap()ed into 50 processes, that requires 13 million
  pv entries.  At 24 bytes per pv entry, that is 314MB of ram and kvm, while
  at 12 bytes it is 157MB.  A 157MB saving is significant.
  
  Test-run by:  scottl (Thanks!)
  
  Revision  Changes    Path
  1.550     +354 -153  src/sys/i386/i386/pmap.c
  1.119     +16 -3     src/sys/i386/include/pmap.h