lkml.org 
[lkml]   [1997]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: New dcache not using slab allocator?
Date
From
Kevin Buhr wrote:
>
> [ Hope you don't mind me ccing this reply to "linux-kernel". ]
>
> Dean Gaudet <dgaudet@arctic.org> writes:
> >
> > filenames probably display a regularity that you can exploit ... such as a
> > mode around 7 or 8 chars. I'm assuming the dcache has just the basename
> > for each entry rather than the full name ... but I've never looked at the
> > code. You could create a slab for the 1 .. 8 char names, and then another
> > for the 9 .. 16, and then just kmalloc the rest. Those numbers would have
> > to be verified by experimentation.
>
> Yup, it's just the basename, and your scheme is right on the money.
>
> In fact, right now the smallest size "kmalloc" objects are 32 bytes,
> so even by introducing a "dname-16" cache (for filenames 1..15
> characters in length), I think we make a big win.

I've benchmarked the "old" kmalloc to find out what was really
getting used.

The result was that "small" allocations end up not taking up much
memory. So an overhead of 24 bytes on a 8 byte filname "feels" bad,
but won't clog your memory significantly.

For example suppose there are only 100 dcache entries:
8,16 and 32 byte entries: total 1 page of 32 byte slots.

If you divide those into different slabs, you'd need a total of 3
pages.

In practise you can have much more than 100 entries before you
"save" memory this way....

Roger.


\
 
 \ /
  Last update: 2005-03-22 13:40    [W:0.033 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site