Messages in this thread | | | Date | Wed, 16 Nov 2005 01:47:43 +0000 (GMT) | From | Mel Gorman <> | Subject | Re: [PATCH 5/5] Light Fragmentation Avoidance V20: 005_configurable |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |