Re: How to parse out kmem output?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




----- Original Message -----
> 
> 
> ----- Original Message -----
> > Hi list,
> > 
> > I am current tracking one issue related with memory.
> > What I want to know if a kernel address which is alloced by kmalloc,
> > 1. whether that address is already freed or not

I should also have mentioned that the address you are looking for could
have been previously allocated, freed, and now it's part of the kmalloc-2048
slab cache where it hasn't been re-allocated yet?  It's hard to tell, but
it doesn't seem to be currently-in-use.

> > 2. if not freed, could I know which task or struct is owning that range?

The owner is not tracked by the SLAB/SLUB subsystem, at least not unless
some type of DEBUG is turned on.  You might try doing a "search" for the
address, and if found, try to determine what the containing addresses
are.

Dave

> > 
> > I am also try to use the kmem command to get more info,
> > but I don't know the meaning for its output...
> > Like "CACHE"/"ALLOCATED"/"TOTAL"/"SLABS" member,
> 
> The CACHE is the kmem_cache structure address.
> The ALLOCATED total is the number of objects that have been
> allocated from the CACHE.
> The TOTAL is the maximum number of objects in the CACHE.
> The SLABS is the number of of SSIZE-sized slabs that are
> current being used to create the TOTAL number of objects.
> 
> > what are they referring to?
> > And according to "FREE / [ALLOCATED]" as below, does it
> > mean that 0xe1416acc already be freed?
> > 
> > crash> kmem -S 0xe1416acc
> > CACHE    NAME                 OBJSIZE  ALLOCATED     TOTAL  SLABS
> >  SSIZE
> > e0002400 kmalloc-2048            2048        156       160     10
> >    32k
> >   SLAB      MEMORY    NODE  TOTAL  ALLOCATED  FREE
> >   c1628200  e1410000     0     12         12     0
> >   FREE / [ALLOCATED]
> >   [e1410000]
> >   [e1410800]
> >   [e1411000]
> >   [e1411800]
> >    e1412000  (cpu 0 cache)
> >    e1412800  (cpu 0 cache)
> >    e1413000  (cpu 0 cache)
> >    e1413800  (cpu 0 cache)
> >    e1414000  (cpu 0 cache)
> >    e1414800  (cpu 0 cache)
> >    e1415000  (cpu 0 cache)
> >   [e1415800]
> > crash>
> 
> The SLUB display indicates that there are 12 objects allocated
> from the "kmalloc-2048" cache, and either they are currently
> in use, or they are sitting on the cpu 0 per-cpu cache.  The
> address that you entered would "fit" into the 32k slab page,
> but it doesn't seem to be allocated or sitting in the cpu 0 cache.
> 
> I believe that means that the object is currently free.
> 
> > Also seems current kmem only support SLAB, right?
> 
> Wait, isn't your kernel CONFIG_SLUB?  Enter "help -v" and look
> at the flags field.  It will show either KMALLOC_SLUB or
> KMALLOC_SLAB.
> CONFIG_SLOB is not supported.
> 
> Dave
> 
> 
> > If memory is allocated with like SLUB or SLOB, could the kmem
> > still handle it?
> > 
> > Thanks,
> > Lei
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/crash-utility
> > 
> 
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
> 

--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux