On Sun, May 21, 2017 at 11:12:00AM -0400, Sarunya Pumma wrote: > After the fault handler performs the __do_fault function to read a fault > page when a page fault occurs, it does not map other pages that have been > read together with the fault page. This can cause a number of minor page > faults to be large. Therefore, this patch is developed to remap pages > around the fault page by aiming to map the pages that have been read > synchronously or asynchronously with the fault page. > > The major function of this patch is the redo_fault_around function. This > function computes the start and end offsets of the pages to be mapped, > determines whether to do the page remapping, remaps pages using the > map_pages function, and returns. In the redo_fault_around function, the > start and end offsets are computed the same way as the do_fault_around > function. To determine whether to do the remapping, we determine if the > pages around the fault page are already mapped. If they are, the remapping > will not be performed. > > As checking every page can be inefficient if a number of pages to be mapped > is large, we have added a threshold called "vm_nr_rempping" to consider > whether to check the status of every page around the fault page or just > some pages. Note that the vm_nr_rempping parameter can be adjusted via the > Sysctl interface. In the case that a number of pages to be mapped is > smaller than the vm_nr_rempping threshold, we check all pages around the > fault page (within the start and end offsets). Otherwise, we check only the > adjacent pages (left and right). > > The page remapping is beneficial when performing the "almost sequential" > page accesses, where pages are accessed in order but some pages are > skipped. > > The following is one example scenario that we can reduce one page fault > every 16 page: > > Assume that we want to access pages sequentially and skip every page that > marked as PG_readahead. Assume that the read-ahead size is 32 pages and the > number of pages to be mapped each time (fault_around_pages) is 16. > > When accessing a page at offset 0, a major page fault occurs, so pages from > page 0 to page 31 is read from the disk to the page cache. With this, page > 24 is marked as a read-ahead page (PG_readahead). Then only page 0 is > mapped to the virtual memory space. > > When accessing a page at offset 1, a minor page fault occurs, pages from > page 0 to page 15 will be mapped. > > We keep accessing pages until page 31. Note that we skip page 24. > > When accessing a page at offset 32, a major page fault occurs. The same > process will be repeated. The other 32 pages will be read from the disk. > Only page 32 is mapped. Then a minor page fault at the next page (page > 33) will occur. > > From this example, two page faults occur every 16 page. With this patch, we > can eliminate the minor page fault in every 16 page. > > Thank you very much for your time for reviewing the patch. > > Signed-off-by: Sarunya Pumma <sarunya@xxxxxx> Still no performance numbers? I doubt it's useful. You woundn't get "a number of minor page faults". The first minor page fault would take faultaround path and map these pages. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
