On Thu, Nov 18, 2010 at 09:38:28AM +0100, Johannes Weiner wrote: > On Thu, Nov 18, 2010 at 05:26:27PM +0900, KAMEZAWA Hiroyuki wrote: > > On Thu, 18 Nov 2010 08:12:54 +0000 > > Mel Gorman <mel@xxxxxxxxx> wrote: > > > > > > > I'm hoping that this series also removes the > > > > > necessity for the "delete lumpy reclaim" patch from the THP tree. > > > > > > > > Now I'm sad. I read all that and was thinking "oh goody, we get to > > > > delete something for once". But no :( > > > > > > > > If you can get this stuff to work nicely, why can't we remove lumpy > > > > reclaim? > > > > > > Ultimately we should be able to. Lumpy reclaim is still there for the > > > !CONFIG_COMPACTION case and to have an option if we find that compaction > > > behaves badly for some reason. > > > > > > > Hmm. CONFIG_COMPACTION depends on CONFIG_MMU. lumpy reclaim will be for NOMMU, > > finally ? > > It's because migration depends on MMU. But we should be able to make > a NOMMU version of migration that just does page cache, which is all > that is reclaimable on NOMMU anyway. > Conceivably, but I see little problem leaving them with lumpy reclaim. As page cache and anon pages are mixed together in MIGRATE_MOVABLE but only one set of pages can be discarded, the success rates of either lumpy reclaim or compaction is doubtful. It'd require a specific investigation. > At this point, the MMU dependency can go away, and so can lumpy > reclaim. > The series never calls lumpy reclaim once CONFIG_COMPACTION is set. The code could be shrunk with the below patch but the saving to vmlinux is minimal (288 bytes for me on x86-64). My preference is still to have lumpy reclaim available as a comparison point with compaction for a development cycle or two. diff --git a/mm/vmscan.c b/mm/vmscan.c index 52a0f0c..7488983 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1048,7 +1048,7 @@ static unsigned long isolate_lru_pages(unsigned long nr_to_scan, BUG(); } - if (!order) + if (!order || COMPACTION_BUILD) continue; /* -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>