> > We'll need something a little more radical, or just halfway
> > radical by counting the contiguous buddies (of eg. 3 pages)
> > and allocating from smaller areas only, giving the larger
> > areas chance to grow.
> >
> > But this is so close to a zone allocator that we might as well
> > do a lot of finetuning right now and start 2.3 real fast...
>
> 2.1.10x isnt usable on a server with 16Mb. It eventually fragments
> itself to death normally death by dcache fragmentation of main
> memory. I suspect a 32Mb box will simply last longer rather than
> survive indefinitely.
Using the slab allocator directly for the dcache could help a lot (instead
of the kmalloc emulation, which is more prone to fragmentation). The problem
is to fit the variable length filename into the slab object cache paradigm.
One possible solution would be to add a default array of e.g. 16 or 32bytes
to the dentry object itself, and only fall back to a separate allocation
if the filename exceeds that [SQL databases use similar techniques for text
fields]
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html