Prev: first round of SCSI updates for the 2.6.36 merge window
Next: lockup_detector: Make DETECT_HUNT_TASK default depend on LOCKUP_DETECTOR
From: Minchan Kim on 5 Aug 2010 21:00 On Thu, Aug 5, 2010 at 11:17 PM, Minchan Kim <minchan.kim(a)gmail.com> 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(a)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 > Ignore above comment. lock_page doesn't have a deadlock problem. My bad. Reviewed-by: Minchan Kim <minchan.kim(a)gmail.com> -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |