lkml.org 
[lkml]   [2010]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/7] vmscan: synchrounous lumpy reclaim use lock_page() instead trylock_page()
    On Thu, Aug 05, 2010 at 03:13:39PM +0900, KOSAKI Motohiro wrote:
    > When synchrounous lumpy reclaim, there is no reason to give up to
    > reclaim pages even if page is locked. We use lock_page() instead
    > trylock_page() in this case.
    >
    > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    > ---
    > mm/vmscan.c | 4 +++-
    > 1 files changed, 3 insertions(+), 1 deletions(-)
    >
    > diff --git a/mm/vmscan.c b/mm/vmscan.c
    > index 1cdc3db..833b6ad 100644
    > --- a/mm/vmscan.c
    > +++ b/mm/vmscan.c
    > @@ -665,7 +665,9 @@ static unsigned long shrink_page_list(struct list_head *page_list,
    > page = lru_to_page(page_list);
    > list_del(&page->lru);
    >
    > - if (!trylock_page(page))
    > + if (sync_writeback == PAGEOUT_IO_SYNC)
    > + lock_page(page);
    > + else if (!trylock_page(page))
    > goto keep;
    >
    > VM_BUG_ON(PageActive(page));
    > --
    > 1.6.5.2
    >
    >
    >

    Hmm. We can make sure lumpy already doesn't select the page locked?
    I mean below scenario.

    LRU head -> page A -> page B -> LRU tail

    lock_page(page A)
    some_function()
    direct reclaim
    select victim page B
    enter lumpy mode
    select victim page A as well as page B
    shrink_page_list
    lock_page(page A)


    --
    Kind regards,
    Minchan Kim


    \
     
     \ /
      Last update: 2010-08-05 16:21    [W:2.805 / U:0.216 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site