Messages in this thread | | | Date | Fri, 22 Feb 2008 14:00:02 +0100 | From | Andi Kleen <> | Subject | Re: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig |
| |
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
| |