On Thu, Mar 30, 2006 at 12:26:58AM +0200, Andi Kleen wrote:
> dentry_cache 999168 1024594 208 19 1 : tunables 120 60 8 :
> slabdata 53926 53926 0 : shrinker stat 18522624 8871000
>
> Hrm interesting is this one:
>
> sock_inode_cache 996784 996805 704 5 1 : tunables 54 27 8 :
> slabdata 199361 199361 0
>
> Most of the leaked dentries seem to be sockets. I didn't notice this earlier.
ITYM "all". You've got 2384 non-socket dentries, which is about what I'd
expect on severely pressured busy system...
> This was with the debugging patches applied btw.
>
> So maybe we have a socket leak?
Looks like that. Note: /proc/slab_allocators won't help here; all allocations
into that cache are done from sock_alloc_inode(), which is what will be shown.
Not useful... Moreover, call chain is predictable several steps deeper than
that: sock_alloc_inode() (as ->alloc_inode()) from alloc_inode() from
new_inode() from sock_alloc().
FWIW... One thing that might be useful here:
a) slab_set_creator(objp, cachep, address): no-op unless DEBUG_SLAB_LEAK set,
void slab_set_creator(void *objp, struct kmem_cache *cachep, void *address)
{
if (cachep->flags & SLAB_STORE_USER)
*dbg_userword(cachep, objp) = address;
}
otherwise (has to be function in mm/slab.c; exported).
b)
void slab_charge_here(void *objp, struct kmem_cache *cachep, void *address)
{
slab_set_creator(objp, cachep, __builtin_return_address(0));
}
in mm/slab.c (exported)
c) #define slab_charge_caller(objp, cachep) \
slab_set_creator((objp), (cachep), __builtin_return_address(0))
Then we can do the following: in sock_alloc() have
slab_charge_caller(container_of(inode, struct socket_alloc, vfs_inode),
sock_inode_cachep);
and _then_ /proc/slab_allocators will charge these guys to callers of
sock_alloc(); if you'll need to pursue it further, you can always slap
more slab_charge_...() where needed.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
