Re: Page allocator: Single Zone optimizations

Andrew Morton
2006-10-26T22:09:38Z

On Mon, 23 Oct 2006 16:08:20 -0700 (PDT)
Christoph Lameter <clameter@sgi.com> wrote:

> Single Zone Optimizations V2
>
> V1->V2 Use a config variable setup im mm/KConfig
>
> If we only have a single zone then various macros can be optimized.
> We do not need to protect higher zones, we know that zones are
> always present, can remove useless data from /proc etc etc. Various
> code paths become unnecessary with a single zone setup.

I don't know about all of this. It's making core mm increasingly revolting
and increases dissimilarities between different kernel builds and generally
makes it harder for us to remotely diagnose and solve people's bug reports.
Harder to understand architecture A's behaviour based upon one's knowledge
of architecture B, etc.

I really really want to drop all those patches[1] and rethink it all.

Like... would it make sense to eliminate the hard-coded concepts of DMA,
DMA32, NORMAL and HIGHMEM and simply say "we support 1 to N zones" per
node? Obviously we'd need to keep the DMA/NORMAL/HIGHMEM nomenclature in
the interfaces so the rest of the kernel builds and works, but the core mm
just shouldn't need to care: all it cares about is one or more zones.

Or something like that. Something which makes the mm easier to understand,
easier to maintain and faster. Rather than harder to understand, harder to
maintain and faster.

[1] These:

get-rid-of-zone_table.patch
deal-with-cases-of-zone_dma-meaning-the-first-zone.patch
get-rid-of-zone_table-fix-3.patch
introduce-config_zone_dma.patch
optional-zone_dma-in-the-vm.patch
optional-zone_dma-in-the-vm-no-gfp_dma-check-in-the-slab-if-no-config_zone_dma-is-set.patch
optional-zone_dma-for-ia64.patch
remove-zone_dma-remains-from-parisc.patch
remove-zone_dma-remains-from-sh-sh64.patch
set-config_zone_dma-for-arches-with-generic_isa_dma.patch
zoneid-fix-up-calculations-for-zoneid_pgshift.patch