lkml.org 
[lkml]   [2010]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC 1/2] deactive invalidated pages
    On Mon, Nov 22, 2010 at 09:01:32PM -0800, Andrew Morton wrote:
    > On Tue, 23 Nov 2010 13:52:05 +0900 Minchan Kim <minchan.kim@gmail.com> wrote:
    >
    > > >> +/*
    > > >> + * Function used to forecefully demote a page to the head of the inactive
    > > >> + * list.
    > > >> + */
    > > >
    > > > This comment is wrong? __The page gets moved to the _tail_ of the
    > > > inactive list?
    > >
    > > No. I add it in _head_ of the inactive list intentionally.
    > > Why I don't add it to _tail_ is that I don't want to be aggressive.
    > > The page might be real working set. So I want to give a chance to
    > > activate it again.
    >
    > Well.. why? The user just tried to toss the page away altogether. If
    > the kernel wasn't able to do that immediately, the best it can do is to
    > toss the page away asap?
    >

    I'm just guessing here on the motivation but maybe it is in case FADV_DONENEED
    was called on a page in use by another process (via read/write more do than
    being mapped). Process A says "I don't need this" but by moving it to the
    head of the list we give Process B a chance to reference it and reactivate
    without incurring a major fault?

    > > If it's not working set, it can be reclaimed easily and it can prevent
    > > active page demotion since inactive list size would be big enough for
    > > not calling shrink_active_list.
    >
    > What is "working set"? Mapped and unmapped pagecache, or are you
    > referring solely to mapped pagecache?
    >
    > If it's mapped pagecache then the user was being a bit silly (or didn't
    > know that some other process had mapped the file). In which case we
    > need to decide what to do - leave the page alone, deactivate it, or
    > half-deactivate it as this patch does.
    >

    What are the odds of an fadvise() user having used mincore() in advance
    to determine if the page was in use by another process? I would guess
    "low" so this half-deactivate gives a chance for the page to be promoted
    again as well as a chance for the flusher threads to clean the page if
    it really is to be reclaimed.

    --
    Mel Gorman
    Part-time Phd Student Linux Technology Center
    University of Limerick IBM Dublin Software Lab


    \
     
     \ /
      Last update: 2010-11-23 10:41    [W:0.021 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site