Hi,

while trying to get more info on the suspected kernel malloc leak
documented in PR#39145, I found it useful to see how many
allocations of each size each malloc type is currently holding.

The diff attached below implements this functionality, by adding
32 u_long's to "struct malloc_type", and when KMEMSTATS is
enabled, it counts allocations and frees to each power-of-two
size accordingly.  "vmstat -m" can then now show:


Memory statistics by type                                Type  Kern
           Type InUse  MemUse HighUse   Limit   Requests Limit Limit Si=
ze(s)
prop dictionary   145     19K     19K  78644K        145     0     0 12=
8:145


etc. etc.

Any comments to me adding this change?  Does this warrant a
kernel version bump because malloc_type changes size?

Best regards,

- H=E5vard
[ message continues ]

Put the u_long after the 'const char *'.
I'm not sure that using u_short is necessary.
If the structure gets copied to userspace you want fixed sized types.
Otherwise what is wrong with 'unsigned int' (instead of size_t).

	David

-- 
David Laight: david@l8s.co.uk
[ message continues ]

Hi,

it's time to pick up an old issue I discussed here earlier.

As described earlier, I'd like to extend vmstat to show the
number of allocations done per type and size, like so:

Memory statistics by type                                Type  Kern
           Type InUse  MemUse HighUse   Limit   Requests Limit Limit Size(s)
   kernfs mount     1      1K      1K  78644K          1     0     0 16:1
    ptyfs mount     1      1K      1K  78644K          1     0     0 16:1
     prop array     1      1K      1K  78644K          1     0     0 64:1
prop dictionary   145     19K     19K  78644K        145     0     0 128:145
    prop string   143      3K      3K  78644K        143     0     0 16:143
           acpi    30      1K      1K  78644K         31     0     0 16:7,32:19,64:4
            USB    46      5K      5K  78644K         52     0     0 16:6,32:6,64:19,128:9,256:6,1024:0
     USB device    18     19K     19K  78644K         18     0     0 16:6,128:3,2048:9

These stats are only available under KMEMSTATS, but since struct
malloc_type is part of what vmstat uses, it would not be friendly
to require a new vmstat just because you turned on KMEMSTATS in
the kernel.  This means that this change will currently consume
around 5-6KB extra kernel memory.  All the counting in the kernel
is however done under KMEMSTATS ifdefs.

While it is apparently true that malloc(9) over time is being
replaced by kmem(9), there remains a large number of uses of
malloc(9) in the kernel, and they are unlikely to go away anytime
soon.

This change is the first stage of a two-stage set of changes
which would make it easier to spot and trace kernel memory leaks
in use of malloc(9), and was of much help finding the kernel
memory leak documented in PRs 39145 and 42661.

The new diff is attached below.  This time I've refrained from
the re-typing of the preexisting fields in "struct malloc_type",
to keep the change as small as possible.

It would appear that in addition to this change, a ...
[ message continues ]

let's learn from the POSIX getline(3) fun we had, and use less generic
names than MINBUCKET and MAXBUCKET, please, especially if they're
going in <sys/param.h>?

thanks,
alistair
[ message continues ]

They are already, but why do they have to be exported in headers at all?
E.g. I would suggest to define them locally in kern_malloc.c and have
corresponding global variables + sysctl for vmstat() and friends.

Joerg
[ message continues ]

In article <20100331162346.GA11685@britannica.bec.de>,

That is what ifdef _KERNEL is there for...

christos

[ message continues ]

For stuff that's shared between kernel and grovellers, _KMEMUSER is
the one to use.


[ message continues ]