>> 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: >> >> >> http://www.sr71.net/patches/2.6.11/2.6.11-bk7-mhp1/broken-out/B-sparse-150-sparsemem.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 about. > 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 > take? Andy, can you explain that further? Maybe also worth checking these are the correct version of your patches. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
