Re: [PATCH 08/14] Memory compaction core

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Andrew Morton
Date: Tuesday, April 6, 2010 - 5:05 pm

On Fri,  2 Apr 2010 17:02:42 +0100
Mel Gorman <mel@csn.ul.ie> wrote:


Confused.  "incomplete" and "partial" are synonyms.  Please fully
document these here.


Why?  What are the implications of this decision?  How was it arrived
at?  What might one expect if one were to alter COMPACT_CLUSTER_MAX?


I'm kinda surprised that we don't already have a function to do this.

An `unsigned' return value would make more sense.  Perhaps even
`unsigned long', unless there's something else here which would prevent
that absurd corner-case.


	end_pfn = min(blockpfn + pageblock_nr_pages, zone_end_pfn);

I find that easier to follow, dunno how others feel.


What does "This assumes the block is valid" mean?  The code checks
pfn_valid_within()..


hm.  pfn_to_page() isn't exactly cheap in some memory models.  I wonder
if there was some partial result we could have locally cached across
the entire loop.


Strange.  Having just busted a pageblock_order-sized higher-order page
into order-0 pages, the loop goes on and inspects the remaining
(1-2^pageblock_order) pages, presumably to no effect.  Perhaps

	for (; blockpfn < end_pfn; blockpfn++) {

should be

	for (; blockpfn < end_pfn; blockpfn += pageblock_nr_pages) {

or somesuch.

btw, is the whole pageblock_order thing as sucky as it seems?  If I
want my VM to be oriented to making order-4-skb-allocations work, I
need to tune it that way, to coopt something the hugepage fetishists
added?  What if I need order-4 skb's _and_ hugepages?


`bool'?


"and then isolate them"?


Well.  This code checks each pfn it touches, but
isolate_freepages_block() doesn't do this - isolate_freepages_block()
happily blunders across a contiguous span of pageframes, assuming that
all those pages are valid, and within the same zone.


For how long can this loop hold of interrupts?


yeah, but what does it do?


Can this happen?

Use max()?


what?


Needs (much) more explanation, please.


... why did it do this?  Quite a head-scratcher.


This test could/should be moved inside the preceding `if' block.  Or,
better, simply do

		if (__isolate_lru_page(page, ISOLATE_BOTH, 0) != 0)
			continue;	/* comment goes here */


newline here please.


ah-hah!  So maybe we meant COMPACT_INTERRUPTED.


If zone->spanned_pages is much much larger than zone->present_pages,
this code will suck rather a bit.  Is there a reason why that can never
happen?


<stares at that for a while>

Perhaps

	while ((ret = compact_finished(zone, cc)) == COMPACT_INCOMPLETE) {

would be clearer.  That would make the definition-site initialisation
of `ret' unneeded too.


newline please.


Boy, this looks like an infinite loop waiting to happen.  Are you sure?
Suppose we hit a pageblock-sized string of !pfn_valid() pfn's, for
example.  Worried.


OK, there is no way in which the code-reader can work out why this is
here.  What deadlock?


Should we present these on CONFIG_COMPACTION=n kernels?



Does all this code really need to iterate across individual pfn's like
this?  We can use the buddy structures to go straight to all of a
zone's order-N free pages, can't we?  Wouldn't that save a whole heap
of fruitless linear searching?
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[PATCH 0/14] Memory Compaction v7, Mel Gorman, (Fri Apr 2, 9:02 am)
[PATCH 08/14] Memory compaction core, Mel Gorman, (Fri Apr 2, 9:02 am)
Re: [PATCH 14/14] mm,migration: Allow the migration of Pag ..., KAMEZAWA Hiroyuki, (Mon Apr 5, 11:54 pm)
[No subject], Tarkan Erimer, (Tue Apr 6, 7:47 am)
[No subject], Mel Gorman, (Tue Apr 6, 8:00 am)
[No subject], Tarkan Erimer, (Tue Apr 6, 8:03 am)
[No subject], Minchan Kim, (Tue Apr 6, 8:37 am)
Re: [PATCH 08/14] Memory compaction core, Andrew Morton, (Tue Apr 6, 5:05 pm)
Re: [PATCH 08/14] Memory compaction core, Mel Gorman, (Wed Apr 7, 8:21 am)
Re: [PATCH 08/14] Memory compaction core, Mel Gorman, (Thu Apr 8, 9:59 am)
Re: [PATCH 08/14] Memory compaction core, Andrea Arcangeli, (Thu Apr 8, 10:06 am)