Re: [PATCH] Bias the location of pages freed for min_free_kbytes inthe same MAX_ORDER_NR_PAGES blocks

From: Andrew Morton
Date: Sun Mar 18 2007 - 14:13:50 EST


On Sun, 18 Mar 2007 11:35:36 +0000 (GMT) Mel Gorman <mel@xxxxxxxxx> wrote:

> > But let me leap ahead of myself.
> >
> >> CONFIG_PAGE_GROUP_BY_MOBILITY
> >
> > Why does this config item exist? It's not good to have some mysterious
> > knob which affects mm behaviour at compile time. We need to make up our
> > minds and stick with it.
> >
>
> The configuration item exists because there were concerns over the memory
> footprint and cache line footprint. It was introduced to address that
> concern and also so that it would be possible to compare the performance
> behavior of anti-fragmentation. Your comment rang a bell though so I
> searched the archives to see this comment from Andi Kleen;
>
> ===
> If anything this should be a boot time option or perhaps sysctl, not a
> config. 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.
>
> Also #ifdef as a documentation device is a really really scary concept.
> Yuck.
> ===
>
> A sysctl would avoid any cache line footprint but not the memory overhead
> because the freelists in struct zone as those freelists would still exist.
> I could make the option depend on CONFIG_EMBEDDED for the zone overhead.
> Would that make sense or would it be preferable to ditch the option
> altogether?
>
> I'll start looking at doing a sysctl so it can be disabled at runtime if
> necessary. I strongly suspect that it cannot be enabled again once
> disabled but I don't see that as a problem as such.

How much additional memory consumption are we expecting here?

Whether it's runtime or compile-time, the optionality is not good.
-
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/