Re: SLUB

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

>> 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>