Re: Please don't beat me up (was Re: Bugs and wishes in memory management area)

Mark Hemment (
Sat, 30 Nov 1996 11:47:01 +0000 (GMT)

On Sat, 30 Nov 1996, Keith Owens wrote:
> On Fri, 29 Nov 1996, Mark Hemment wrote:
> > If you know the usage patterns, it is possible to design
> > efficient allocators for specific applications. Difficult to do in a
> > kernel.

> Completely blue sky. Would it be possible to tune the allocation
> algorithms by identifying the most common sizes and feeding parameters
> back into the allocator? Either through /proc or (if all else fails)
> by recompiling with a modified header.

It's possible to tune the current kmalloc(). Mainly to confirm the
sizes of its buffers are good (no point having sizes; 508 and 1020 when
most allocations in that range are at 510 bytes). Has someone checked
the sizes, or produced /proc/kmalloc stats patch?
In kmalloc() it's _not_ possible to tune how many pages are used for a
certain buffer size - take a look at the PAGE_DESC() macro kmalloc.c, it
assumes the release pointer is on the first page of an 'area'. This helps
keeps the code simply, but if a blocksize has a high hit count
then it _might_ be better to take 2 (or 4) pages from the VM subsystem
at a time.

Most allocation algorithms allow themselves to be tuned as above.
I was refering to collecting usage patterns in deciding which algorithm to
use. Your point on tuning an allocator is true. If I can't find a
patch for /proc, I'll quickly write one. (BTW, my Slab allocator patch
has a /proc/slabinfo which tells you useful info; such as number of task
structures, inode structures, etc, allocated in your system along with
the number of pages used by them).