Re: [PATCH 0/4] sparsemem intro patches
From: Martin J. Bligh
Date: Tue Mar 15 2005 - 09:57:53 EST
>> The following four patches provide the last needed changes before the
>> introduction of sparsemem. For a more complete description of what this
>> will do, please see this patch:
> I don't know what to think about this. Can you describe sparsemem a little
> further, differentiate it from discontigmem and tell us why we want one?
> Is it for memory hotplug? If so, how does it support hotplug?
> To which architectures is this useful, and what is the attitude of the
> relevant maintenance teams?
This isn't just for hotplug by any means. Andy wrote it to get rid of a whole
bunch of different problems, roughly based on some previous work by Dan Phillips
and Dave McCracken (I've added a cc to the actual authors of these patches).
This is the major part of what used to be called CONFIG_NONLINEAR, which we
discussed at last year's kernel summit, and people were pretty enthusiastic
> Quoting from the above patch:
>> Sparsemem replaces DISCONTIGMEM when enabled, and it is hoped that
>> it can eventually become a complete replacement.
>> This patch introduces CONFIG_FLATMEM. It is used in almost all
>> cases where there used to be an #ifndef DISCONTIG, because
>> SPARSEMEM and DISCONTIGMEM often have to compile out the same areas
>> of code.
> Would I be right to worry about increasing complexity, decreased
> maintainability and generally increasing mayhem?
Not really - it cleans up the current mess where discontigmem means, and
is used for, two distinct things: 1. the memory is significantly non-contig
in the physical layout. 2. NUMA support.
It also allows us to support discontiguous memory *within* a NUMA node, which
is important for some systems - we can scrap the added complexity of ia64s
vmemmap stuff, for instance.
Whatever your opinions are on mem hotplug, I think we want CONFIG_SPARSEMEM
to clean up the existing mess of discontig - with or without hotplug. I've
wanted this for a very long time, and was dicussing it with Andy at OLS last
year; he came up with a much better, cleaner way to implement it than I had.
It also makes a lot of sense as a foundation for hotplug, which multiple
people seem to want for virtualization stuff.
Anyway, that's what I want it for ;-)
> If a competent kernel developer who is not familiar with how all this code
> hangs together wishes to acquaint himself with it, what steps should he
Andy, can you explain that further? Maybe also worth checking these are the
correct version of your patches.
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/