Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 3 Apr 2006 21:36:01 +0000 (UTC)
From:      Peter Wemm <peter@FreeBSD.org>
To:        src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   cvs commit: src/sys/amd64/amd64 pmap.c src/sys/amd64/include pmap.h
Message-ID:  <200604032136.k33La1gw062206@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
peter       2006-04-03 21:36:01 UTC

  FreeBSD src repository

  Modified files:
    sys/amd64/amd64      pmap.c 
    sys/amd64/include    pmap.h 
  Log:
  Shrink the amd64 pv entry from 48 bytes to about 24 bytes.  On a machine
  with large mmap files mapped into many processes, this saves hundreds of
  megabytes of ram.
  pv entries were individually allocated and had two tailq entries and two
  pointers (or addresses).  Each pv entry was linked to a vm_page_t and
  a process's address space (pmap).  It had the virtual address and a
  pointer to the pmap.
  This change replaces the individual allocation with a per-process
  allocation system.  A page ("pv chunk") is allocated and this provides
  168 pv entries for that process.  We can now eliminate one of the 16 byte
  tailq entries because we can simply iterate through the pv chunks to find
  all the pv entries for a process.  We can eliminate one of the 8 byte
  pointers because the location of the pv entry implies the containing
  pv chunk, which has the pointer.  After overheads from the pv chunk
  bitmap and tailq linkage, this works out that each pv entry has an
  effective size of 24.38 bytes.
  
  Future work still required, and other problems:
  * when running low on pv entries or system ram, we may need to defrag
    the chunk pages and free any spares.  The stats (vm.pmap.*) show that
    this doesn't seem to be that much of a problem, but it can be done if
    needed.
  * running low on pv entries is now a much bigger problem.  The old
    get_pv_entry() routine just needed to reclaim one other pv entry.
    Now, since they are per-process, we can only use pv entries that are
    assigned to our current process, or by stealing an entire page worth
    from another process.  Under normal circumstances, the pmap_collect()
    code should be able to dislodge some pv entries from the current
    process.  But if needed, it can still reclaim entire pv chunk pages
    from other processes.
  * This should port to i386 really easily, except there it would reduce
    pv entries from 24 bytes to about 12 bytes.
  
  (I have integrated Alan's recent changes.)
  
  Revision  Changes    Path
  1.542     +293 -148  src/sys/amd64/amd64/pmap.c
  1.130     +16 -3     src/sys/amd64/include/pmap.h



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