Messages in this thread | | | Date | Sun, 29 Feb 2004 02:39:24 +0100 | From | Andrea Arcangeli <> | Subject | Re: 2.4.23aa2 (bugfixes and important VM improvements for the high end) |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |