To generate the data, I telnetted to localhost --- an attempt to
exercise the networking code at least vaguely --- and compiled about
the first 25% of kernel 1.3.76 (1.3.75 was running at the time). For
a total 26882 calls to kmalloc/kfree, 24205 were for blocks of size 56
bytes! In fact,
no. requests size requested
24205 56
303 988
303 84
303 516
303 16
303 1060
211 96
211 19
139 160
[ descends into noise]
Some exploration later, I found that sizeof(struct vm_area_struct)
==56, which probably accounts for most of them. Any takers for the
988, 1060 or 516? The latter two are, upsettingly, marginally larger
than will tessellate neatly.
Any practical use for this? I don't know yet (I plan to carry on
looking at it; it's that or finals revision ;-) but maybe someone
would like to annotate the definition of vm_area_struct with a
noticeable warning about `add an extra field to this and watch the
fragmentation fly'. And, I guess, check the size on non-386 systems
and see if it fits neatly there too or not. :-)
If anyone's interested in this, they can view a graph of `bytes in
use' against `allocation time in megabytes' for the five most popular
size requests, which I will put on the web as
http://ftp.linux.org.uk/~barlow/kmalloc-trace.gif. I'm not sure what
if anything it signifies.
You can roll your own logging kmalloc with two printk()s, but _don't_
_run_ _klogd_ (or a syslogd that reads from /proc/kmsg) --- it tends
to trigger kmalloc requests :-). Use "cat /proc/kmsg >file" instead.
Thoughts?
Daniel
-- http://ftp.linux.org.uk/~barlow/, dan@detached.demon.co.uk, PGP key ID 5F263625``Consistency is the last refuge of the unimaginative'' --- Oscar Wilde
