lkml.org 
[lkml]   [1996]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: kmalloc: 56 is the answer to Linux, the Universe and Everything
> no. requests       size requested
> 24205 56 struct vm_area_struct
> 303 988 struct task_struct
> 303 84 struct mm_struct
> 303 516 struct signal_struct
> 303 16 struct fs_struct
> 303 1060 struct files_struct
>
>I only went through the 'easy' requests - those with 303 requests.
>They come from creating new tasks, but all of the structures are
>allocated seperately. I decreased NR_OPEN on my system to 246 and am now
>enjoying an extra 8-10 pages of free memory (yeah). NR_OPEN is defined
>in linux/fs.h and limits.h. signal_struct can't be helped, but maybe
>there is a way to attach it to some of the other allocations... Or
>perhaps a kmalloc that better deals with these allocations should be
>written. Any ideas?

I guessed it was the task creation, chiefly from looking at the graph;
it's kind of saw-toothed. Diddling the struct sizes seems a bit of a
dead end, to me; signal_struct will in any case change when POSIX 4
signals come in (I assume). I'd prefer a kmalloc which can do
arbitrary sizes.

I did some more `analysis'; in particular, by logging the address that
kmalloc was called from it gets a lot easier to track things down. I
also tried to collect some data on a networked machine.

When networking comes into the picture, the big wastage seems to come
from nfs (surprise ...). Most networking allocations are for less
than 508 bytes, but a 2048 byte kmalloc actually gets given 4080 bytes
--- a full page, in other words. On the other hand, at least when I
tested, it only seemed to use one page at a a time.
<http://ftp.linux.org.uk/~barlow/kmalloc/>; go and take a look in the
subdirectories.

A simple enhancement might be for kmalloc of between 2040 bytes and a
page to get handed straight off to __get_free_pages, and for kfree(p)
to test if p is page aligned before messing with its lists. The
problem is that you then lose the ability to check that the pointer
passed to kfree is genuine.

Another possibility (given that the size classes _aren't_ powers of
two anyway) is to introduce a couple more of them. 670 bytes, say.

Daniel
--
Daniel Barlow, http://ftp.linux.org.uk/~barlow, daniel.barlow@sjc.ox.ac.uk

panic("bad_user_access_length executed (not cool, dude)");



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