File:  [NetBSD Developer Wiki] / wikisrc / projects / project / page_queues.mdwn
Revision 1.3: download - view: text, annotated - select for diffs
Sat Mar 28 17:42:27 2020 UTC (2 years, 4 months ago) by maya
Branches: MAIN
CVS tags: HEAD
mark done by ad@

    1: [[!template id=project
    2: 
    3: title="Parallelize page queues"
    4: 
    5: contact="""
    6: [tech-kern](mailto:tech-kern@NetBSD.org)
    7: """
    8: 
    9: mentors="""
   10: [Taylor R Campbell](mailto:riastradh@NetBSD.org),
   11: [Matthew R. Green](mailto:mrg@NetBSD.org),
   12: [Chuck Silvers](mailto:chs@NetBSD.org)
   13: """
   14: 
   15: category="kernel"
   16: difficulty="hard"
   17: done_by="Andrew Doran"
   18: 
   19: description="""
   20: For many resource-intensive applications on NetBSD, the biggest
   21:  bottlenecks in the operating system are physical page allocation and
   22:  mapping -- specifically, contention over the centralized queues of free
   23:  pages and of cached pages that can be freed, and over acquiring
   24:  references to pages that are already allocated.
   25: 
   26: This can be broken into three independent milestones:
   27: 
   28: 1. The queues of pages that are currently free.
   29: Although there are per-CPU queues, access to the queues is serialized
   30:  under the single global lock uvm_fpageqlock.
   31: Instead, access to the per-CPU queues should be done on the local CPU
   32:  without talking to the other CPUs unless the per-CPU queue runs out.
   33: 
   34: 2. When memory is short, the part of the system called the page daemon
   35:  must choose some cached pages to free.
   36: The page daemon currently maintains queues of active and inactive
   37:  pages, to prefer freeing up inactive pages.
   38: Access to these is serialized by another global lock, uvm_pageqlock.
   39: Instead, the page daemon should be modified so that adjusting page
   40:  activity is not globally serialized.
   41: 
   42: 3. A related bottleneck is acquiring references to physical pages from
   43:  a frequently used virtual memory object, such as the libc.so file,
   44:  which is serialized by a per-file lock, the vmobjlock, that is a
   45:  bottleneck for, e.g., executing new processes.
   46: The nature of the contention needs to be analyzed: is the bottleneck in
   47:  acquiring different physical pages from the VM object, or the same
   48:  ones?
   49: If it's mostly different physical pages, breaking vmobjlock into
   50:  multiple locks may suffice; if it's mostly the same physical pages, a
   51:  new strategy is needed, e.g. perhaps a lockless radix tree.
   52: """
   53: ]]

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb