Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Jun 2007 04:57:06 +0000 (UTC)
From:      Alan Cox <alc@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/conf NOTES files options src/sys/powerpc/include vmparam.h src/sys/sun4v/sun4v pmap.c src/sys/vm vm_contig.c vm_object.c vm_page.c vm_page.h vm_pageout.c vm_pageq.c vm_zeroidle.c
Message-ID:  <200706160457.l5G4v6NG047392@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
alc         2007-06-16 04:57:06 UTC

  FreeBSD src repository

  Modified files:
    sys/conf             NOTES files options 
    sys/powerpc/include  vmparam.h 
    sys/sun4v/sun4v      pmap.c 
    sys/vm               vm_contig.c vm_object.c vm_page.c 
                         vm_page.h vm_pageout.c vm_pageq.c 
                         vm_zeroidle.c 
  Log:
  Enable the new physical memory allocator.
  
  This allocator uses a binary buddy system with a twist.  First and
  foremost, this allocator is required to support the implementation of
  superpages.  As a side effect, it enables a more robust implementation
  of contigmalloc(9).  Moreover, this reimplementation of
  contigmalloc(9) eliminates the acquisition of Giant by
  contigmalloc(..., M_NOWAIT, ...).
  
  The twist is that this allocator tries to reduce the number of TLB
  misses incurred by accesses through a direct map to small, UMA-managed
  objects and page table pages.  Roughly speaking, the physical pages
  that are allocated for such purposes are clustered together in the
  physical address space.  The performance benefits vary.  In the most
  extreme case, a uniprocessor kernel running on an Opteron, I measured
  an 18% reduction in system time during a buildworld.
  
  This allocator does not implement page coloring.  The reason is that
  superpages have much the same effect.  The contiguous physical memory
  allocation necessary for a superpage is inherently colored.
  
  Finally, the one caveat is that this allocator does not effectively
  support prezeroed pages.  I hope this is temporary.  On i386, this is
  a slight pessimization.  However, on amd64, the beneficial effects of
  the direct-map optimization outweigh the ill effects.  I speculate
  that this is true in general of machines with a direct map.
  
  Approved by:    re
  
  Revision  Changes    Path
  1.1434    +0 -4      src/sys/conf/NOTES
  1.1222    +1 -0      src/sys/conf/files
  1.596     +0 -1      src/sys/conf/options
  1.9       +18 -0     src/sys/powerpc/include/vmparam.h
  1.39      +3 -2      src/sys/sun4v/sun4v/pmap.c
  1.62      +43 -375   src/sys/vm/vm_contig.c
  1.382     +3 -33     src/sys/vm/vm_object.c
  1.348     +43 -54    src/sys/vm/vm_page.c
  1.149     +21 -45    src/sys/vm/vm_page.h
  1.286     +6 -13     src/sys/vm/vm_pageout.c
  1.34      +2 -190    src/sys/vm/vm_pageq.c
  1.48      +3 -18     src/sys/vm/vm_zeroidle.c



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706160457.l5G4v6NG047392>