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@xxxxxxxxxxxxxx> > --- > 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>