Messages in this thread | | | Date | Sun, 12 Jul 1998 09:23:30 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Strange interrupt behaviour |
| |
On 12 Jul 1998, Andi Kleen wrote: > > 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.
The other problem is that the slab code does even more of what people are complaining that fork() does - it grabs multiple pages in order to get nicer cache colouring.
> 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]
Right now the dcache already does try to do this, by rounding up the file name length to a multiple of 16 (see NAME_ALLOC_LEN() for how to change this). So most name allocations _are_ actually of the same size (I bet that 99% of all dentry names are 16 byte allocations in most cases).
However, even though we do the allocation in default sizes, we do not do them together. The reason for that is that it made renaming fairly painful (we _used_ to actually allocate the dentry and the name together, and when renaming we had to re-allocate the whole chunk - which was horrible because we didn't even know who all had pointers to it).
I certainly agree that we might have a 16-byte "default allocation" inside the dentry, and have the name pointer point to that when it is enough. That would work - waste some memory when there are names longer than 16 bytes, but those are rare, and it would save memory for the default case by having just one allocation.
Andi, do you want to look into this?
Linus
- 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
| |