From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <476AFC6C.3080903@hp.com> Date: Thu, 20 Dec 2007 18:36:12 -0500 From: Mark Seger MIME-Version: 1.0 Subject: Re: SLUB References: <476A850A.1080807@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: linux-mm@kvack.org List-ID: >> 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/ 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 // 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: email@kvack.org