Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end)

[Andrea Arcangeli <andrea@suse.de>]

On Sat, Feb 28, 2004 at 01:46:47PM +0100, Andi Kleen wrote:
> Andrea Arcangeli <andrea@suse.de> writes:
> > 
> > we can add a config option to enable together with 2.5:1.5 to drop the
> > gap page in vmalloc, and to reduce the vmalloc space, so that we can
> > sneak another few "free" dozen megs back for the 64G kernel just to get
> > more margin even if we don't strictly need it. (btw, the vmalloc space
> > is also tunable at boot, so this config option would just change the
> > default value)
> 
> Not sure if that would help, but you could relatively easily save
> 8 bytes on 32bit for each vma too. Replace vm_next with rb_next()
> and move vm_rb.color into vm_flags. It would be a lot of editing

the vm_flags rb_color thing is a smart idea indeed, I never thought
about it using vm_flags itself, however it clearly needs a generic
wrapper since we want to keep the rbtree completely generic. David
Woodhouse once suggested me to use the least significant bit of one of
the pointers to save the rb_color, that could work but that really
messes the code up since such a pointer would need to be masked every
time, and it's not self contained. Using vm_flags sounds more
interesting since the pointers are still usable in raw mode, one only
needs to be careful about the locking: vm_flags seems pretty much a
readonly thing so it's probably ok, if there would be other writers
outside the rbtree code then we'd need to sure they're serialized.

you're wrong about s/vm_next/rb_next()/, walking the tree like in
get_unmapped_area would require recurisve algos w/o vm_next, or
significant heap allocations. that's the only thing vm_next is needed
for (i.e. to walk the tree in order efficiently). only if we drop all
tree walks than we can nuke vm_next.

> work though. NUMA API will add new 4 bytes again. 

saving in vmas is partly already accomplished by remap_file_pages, so I
don't rate vma size as critical.