Re: [PATCH 5/5] Light Fragmentation Avoidance V20: 005_configurable

[Mel Gorman]

On Wed, 16 Nov 2005, Andi Kleen wrote:

> On Tuesday 15 November 2005 17:50, Mel Gorman wrote:
> > The anti-defragmentation strategy has memory overhead. This patch allows
> > the strategy to be disabled for small memory systems or if it is known the
> > workload is suffering because of the strategy. It also acts to show where
> > the anti-defrag strategy interacts with the standard buddy allocator.
>
> If anything this should be a boot time option or perhaps sysctl, not a config.

I'll take a look at what's involved in doing this. Using a compile time
option, I was depending on the compiler to see that

for (i = 0; i < RCLM_TYPES; i++) {}

would only every iterate once and get rid of the loop. If I think there is
any chance of these patches getting merged, I'll work on making this a
sysctl or boot-time option rather than a compile option.

> In general CONFIGs that change runtime behaviour are evil - just makes
> changing the option more painful, causes problems for distribution
> users, doesn't make much sense, etc.etc.
>

Agreed, but I felt that some mechanism for disabling this for small
systems was desirable. As it is right now, I see this as a
very-small-memory-available option.

> Also #ifdef as a documentation device is a really really scary concept.
> Yuck.
>

Can't argue with you there. However, for the purposes of discussion here,
it shows exactly where anti-defrag affects the current allocator.

-- 
Mel Gorman
Part-time Phd Student                          Java Applications Developer
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/