Return to page_queues.mdwn CVS log

Up to [NetBSD Developer Wiki] / wikisrc / projects / project

Annotation of wikisrc/projects/project/page_queues.mdwn, revision 1.3

1.1       riastrad    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),
1.2       riastrad   12: [Chuck Silvers](mailto:chs@NetBSD.org)
1.1       riastrad   13: """
                     14: 
                     15: category="kernel"
                     16: difficulty="hard"
1.3     ! maya       17: done_by="Andrew Doran"
1.1       riastrad   18: 
                     19: description="""
                     20: For many resource-intensive applications on NetBSD, the biggest
1.2       riastrad   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.
1.1       riastrad   33: 
                     34: 2. When memory is short, the part of the system called the page daemon
1.2       riastrad   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.
1.1       riastrad   41: 
                     42: 3. A related bottleneck is acquiring references to physical pages from
1.2       riastrad   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.
1.1       riastrad   52: """
                     53: ]]