Messages in this thread |  | | Date | Sat, 30 Nov 1996 11:47:01 +0000 (GMT) | From | Mark Hemment <> | Subject | Re: 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
|  |