lkml.org 
[lkml]   [1996]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Please don't beat me up (was Re: Bugs and wishes in memory management area)


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).

Regards,
markhe


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