Re: [PATCH 12/14] Add a tunable that decides when memory should becompacted and when it should be reclaimed
From: Mel Gorman
Date: Wed Apr 07 2010 - 12:12:11 EST
On Tue, Apr 06, 2010 at 05:06:13PM -0700, Andrew Morton wrote:
> On Fri, 2 Apr 2010 17:02:46 +0100
> Mel Gorman <mel@xxxxxxxxx> wrote:
> > The kernel applies some heuristics when deciding if memory should be
> > compacted or reclaimed to satisfy a high-order allocation. One of these
> > is based on the fragmentation. If the index is below 500, memory will
> > not be compacted. This choice is arbitrary and not based on data. To
> > help optimise the system and set a sensible default for this value, this
> > patch adds a sysctl extfrag_threshold. The kernel will only compact
> > memory if the fragmentation index is above the extfrag_threshold.
> Was this the most robust, reliable, no-2am-phone-calls thing we could
> have done?
> What about, say, just doing a bit of both until something worked?
I guess you could but that is not a million miles away from what
This heuristic is basically "based on free memory layout, how likely is
compaction to succeed?". It makes a decision based on that. A later
patch then checks if the guess was right. If not, just try direct
reclaim for a bit before trying compaction again.
> extra smarts we could remember what worked best last time, and make
> ourselves more likely to try that next time.
With the later patch, this is essentially what we do. Granted we
remember the opposite "If the kernel guesses wrong, then don't compact
for a short while before trying again".
> Or whatever, but extfrag_threshold must die! And replacing it with a
> hardwired constant doesn't count ;)
I think what you have in mind is "just try compaction every time" but my
concern about that is we'll hit a corner case where a lot of CPU time is
taken scanning zones uselessly. That is what this heuristic and the
back-off logic in a later patch was meant to avoid. I haven't thought of
a better alternative :/
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/