Messages in this thread | | | Date | Sat, 30 Apr 2011 00:18:02 +0900 | Subject | Re: [RFC 3/8] vmscan: make isolate_lru_page with filter aware | From | Minchan Kim <> |
| |
On Thu, Apr 28, 2011 at 7:35 PM, Mel Gorman <mgorman@suse.de> wrote: > On Wed, Apr 27, 2011 at 01:25:20AM +0900, Minchan Kim wrote: >> In some __zone_reclaim case, we don't want to shrink mapped page. >> Nonetheless, we have isolated mapped page and re-add it into >> LRU's head. It's unnecessary CPU overhead and makes LRU churning. >> >> Of course, when we isolate the page, the page might be mapped but >> when we try to migrate the page, the page would be not mapped. >> So it could be migrated. But race is rare and although it happens, >> it's no big deal. >> >> Cc: Christoph Lameter <cl@linux.com> >> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> >> Cc: Mel Gorman <mgorman@suse.de> >> Cc: Rik van Riel <riel@redhat.com> >> Cc: Andrea Arcangeli <aarcange@redhat.com> >> Signed-off-by: Minchan Kim <minchan.kim@gmail.com> > >> index 71d2da9..e8d6190 100644 >> --- a/mm/vmscan.c >> +++ b/mm/vmscan.c >> @@ -1147,7 +1147,8 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, >> >> static unsigned long isolate_pages_global(unsigned long nr, >> struct list_head *dst, >> - unsigned long *scanned, int order, >> + unsigned long *scanned, >> + struct scan_control *sc, >> int mode, struct zone *z, >> int active, int file) >> { >> @@ -1156,8 +1157,8 @@ static unsigned long isolate_pages_global(unsigned long nr, >> lru += LRU_ACTIVE; >> if (file) >> lru += LRU_FILE; >> - return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, order, >> - mode, file, 0, 0); >> + return isolate_lru_pages(nr, &z->lru[lru].list, dst, scanned, sc->order, >> + mode, file, 0, !sc->may_unmap); >> } >> > > Why not take may_writepage into account for dirty pages?
I missed it. I will consider it in next version. Thanks, Mel.
-- 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/
| |