On Fri, Feb 22, 2008 at 05:44:47PM +0530, Balbir Singh wrote: > > My concern with all the points you mentioned is that this solution might need > to > change again,
No why would it need to change again? > depending on the factors you've mentioned. vmalloc() is good and > straightforward, but it has these dependencies which could call for another > rewrite of the code. The hotplug change would not need a rewrite of anything, just some additional code in the SRAT parser to increase __VMALLOC_RESERVE for each hotplug region. It's likely <= 3 additional lines. > > > > >>>> if we decided to use vmalloc space, we would need 64 > >>>> MB of vmalloc'ed memory > >>> Yes and if you increase mem_map you need exactly the same space > >>> in lowmem too. So increasing the vmalloc reservation for this is > >>> equivalent. Just make sure you use highmem backed vmalloc. > >>> > >> I see two problems with using vmalloc. One, the reservation needs to be > >> done > >> across architectures. > > > > Only on 32bit. Ok hacking it into all 32bit architectures might be > > difficult, but I assume it would be ok to rely on the architecture > > maintainers for that and only enable it on some selected architectures > > using Kconfig for now. > > > > Yes, but that's not such a good idea Waiting for the maintainers? Why not? I assume the memory controller would be primarily used on larger systems anyways and except for i386 these should be mostly 64bit these days anyways. > > On 64bit vmalloc should be by default large enough so it could > > be enabled for all 64bit architectures. > > > >> Two, a big vmalloc chunk is not node aware, > > > > vmalloc_node() > > > > vmalloc_node() would need to work much the same way as mem_map does. I am would? It already is implemented and works just fine AFAIK. I don't understand the rest of your point. -Andi -- 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/
