lkml.org 
[lkml]   [2004]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Anticipatory prefaulting in the page fault handler V1
    > The page fault handler for anonymous pages can generate significant overhead
    > apart from its essential function which is to clear and setup a new page
    > table entry for a never accessed memory location. This overhead increases
    > significantly in an SMP environment.
    >
    > In the page table scalability patches, we addressed the issue by changing
    > the locking scheme so that multiple fault handlers are able to be processed
    > concurrently on multiple cpus. This patch attempts to aggregate multiple
    > page faults into a single one. It does that by noting
    > anonymous page faults generated in sequence by an application.
    >
    > If a fault occurred for page x and is then followed by page x+1 then it may
    > be reasonable to expect another page fault at x+2 in the future. If page
    > table entries for x+1 and x+2 would be prepared in the fault handling for
    > page x+1 then the overhead of taking a fault for x+2 is avoided. However
    > page x+2 may never be used and thus we may have increased the rss
    > of an application unnecessarily. The swapper will take care of removing
    > that page if memory should get tight.

    I tried benchmarking it ... but processes just segfault all the time.
    Any chance you could try it out on SMP ia32 system?

    M.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:3.875 / U:0.256 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site