Messages in this thread | | | Date | Fri, 6 Aug 2010 09:52:37 +0900 | Subject | Re: [PATCH 3/7] vmscan: synchrounous lumpy reclaim use lock_page() instead trylock_page() | From | Minchan Kim <> |
| |
On Thu, Aug 5, 2010 at 11:17 PM, Minchan Kim <minchan.kim@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@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@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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |