Re: SLUB

[Mark Seger <Mark.Seger@hp.com>]

I did some preliminary prototyping and I guess I'm not sure of the 
math.  If I understand what you're saying, an object has a particular 
size, but given the fact that you may need alignment, the true size is 
really the slab size, and the difference is the overhead.  What I don't 
understand is how to calculate how much memory a particular slab takes 
up.  If the slabsize is really the size of an object, wouldn't I 
multiple that times the number of objects?  But when I do that I get a 
number smaller than that reported in /proc/meminfo, in my case 15997K vs 
17388K.  Given memory numbers rarely seem to add up maybe this IS close 
enough?  If so, what's the significance of the number of slabs?  Would I 
divide the 15997K by the number of slabs to find out how big a single 
slab is?  I would have thought that's what the slab_size is but clearly 
it isn't.

In any event, here's a table of what I see on my machine.  The first 4 
columns come from /sys/slab and the 5th I calculated by just multiplying 
SlabSize X NumObj.  If I should be doing something else, please tell 
me.  Also be sure to tell me if I should include other data.  For 
example, the number of objects is a little misleading since when I look 
at the file I really see something like:

49 N0=19 N1=30

which I'm guessing may mean 19 objects are allocated to socket 0 and 30 
to socket 1?  this is a dual-core, dual-socket system.

-mark

Mark Seger wrote:
>
>>> Perhaps someone would like to take this discussion off-line with me 
>>> and even
>>> collaborate with me on enhancements for slub in collectl?
> sounds good to me, I just didn't want to annoy anyone...
>>> I think we better keep it public (so that it goes into the archive). 
>>> Here a short description of the field in 
>>> /sys/kernel/slab/<slabcache> that you would need
>>>
>>> -r--r--r-- 1 root root 4096 Dec 20 11:41 object_size
>>>
>>> The size of an object. Subtract slab_size - object_size and you have 
>>> the per object overhead generated by alignements and slab metadata. 
>>> Does not change you only need to read this once.
>>>
>>> -r--r--r-- 1 root root 4096 Dec 20 11:41 objects
>>>
>>> Number of objects in use. This changes and you may want to monitor it.
>>>
>>> -r--r--r-- 1 root root 4096 Dec 20 11:41 slab_size
>>>
>>> Total memory used for a single object. Read this only once.
>>>
>>> -r--r--r-- 1 root root 4096 Dec 20 11:41 slabs
>>>
>>> Number of slab pages in use for this slab cache. May change if slab 
>>> is extended.
>>>     
> What I'm not sure about is how this maps to the old slab info.  
> Specifically, I believe in the old model one reported on the size 
> taken up by the slabs (number of slabs X number of objects/slab X 
> object size).  There was a second size for the actual number of 
> objects in use, so in my report that looked like this:
>
> #                      <-----------Objects----------><---------Slab 
> Allocation------>
> #Name                  InUse   Bytes   Alloc   Bytes   InUse   Bytes   
> Total   Bytes
> nfs_direct_cache           0       0       0       0       0       
> 0       0       0
> nfs_write_data            36   27648      40   30720       8   
> 32768       8   32768
>
> the slab allocation was real memory allocated (which should come close 
> to Slab: in /proc/meminfo, right?) for the slabs while the object 
> bytes were those in use.  Is it worth it to continue this model or do 
> thing work differently.   It sounds like I can still do this with the 
> numbers you've pointed me to above and I do now realize I only need to 
> monitor the number of slabs and the number of objects since the others 
> are constants.
>
> To get back to my original question, I'd like to make sure that I'm 
> reporting useful information and not just data for the sake of it.  In 
> one of your postings I saw a report you had that showed:
>
> slubinfo - version: 1.0
> # name            <objects> <order> <objsize> <slabs>/<partial>/<cpu> 
> <flags> <nodes>
>
> How useful is order, cpu, flags and nodes?
> Do people really care about how much memory is taken up by objects vs 
> slabs?  If not, I could see reporting for each slab:
> - object size
> - number objects
> - slab size
> - number of slabs
> - total memory (slab size X number of slabs)
> - whatever else people might think to be useful such as order, cpu, 
> flags, etc
>
> Another thing I noticed is a number of the slabs are simply links to 
> the same base name and is it sufficient to just report the base names 
> and not those linked to it?  Seems reasonable to me...
>
> The interesting thing about collectl is that it's written in perl (but 
> I'm trying to be very careful to keep it efficient and it tends to use 
> <0.1% cpu when run as a daemon) and the good news is it's pretty easy 
> to get something implemented, depending on my free time.  If we can 
> get some level of agreement on what seems useful I could get a version 
> up fairly quickly for people to start playing with if there is any 
> interest.
>
> -mark
>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>