On Thu, Aug 5, 2010 at 11:17 PM, Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > 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 > Ignore above comment. lock_page doesn't have a deadlock problem. My bad. Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx> -- 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