File:  [NetBSD Developer Wiki] / wikisrc / projects / project / page_queues.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Mon Feb 22 20:45:29 2016 UTC (6 years, 5 months ago) by riastradh
Branches: MAIN
CVS tags: HEAD
Tweak formatting.  Fix comma.

    1: [[!template id=project
    3: title="Parallelize page queues"
    5: contact="""
    6: [tech-kern](
    7: """
    9: mentors="""
   10: [Taylor R Campbell](,
   11: [Matthew R. Green](,
   12: [Chuck Silvers](
   13: """
   15: category="kernel"
   16: difficulty="hard"
   17: duration="2-3 months"
   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.
   26: This can be broken into three independent milestones:
   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.
   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.
   42: 3. A related bottleneck is acquiring references to physical pages from
   43:  a frequently used virtual memory object, such as the 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: ]]
   55: [[!tag gsoc]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb