Cc: Ingo Molnar <mingo@...>, Andi Kleen <andi@...>, Christoph Lameter <clameter@...>, Peter Zijlstra <a.p.zijlstra@...>, Steven Rostedt <rostedt@...>, LKML <linux-kernel@...>, Andrew Morton <akpm@...>, Christoph Hellwig <hch@...>, Rafael J. Wysocki <rjw@...>
On Sat, Dec 22, 2007 at 10:01:37AM -0800, Linus Torvalds wrote:
That's probably because the people who are most likely to be using
/proc/slabinfo tend to people people using kernels in production
environments, and they probably haven't started playing with SLUB yet.
So the fact we haven't heard the yelling doesn't necessarily mean that
people won't notice.
I know of a number of debugging scripts that periodically poll
/proc/slabinfo to find out what is using memory and to track trends
and predict potential problems with memory usage and balance. Indeed,
I've left several such scripts behind at various customer
installations after debugging memory usage problems, and some system
administrators very much like being able to collect that information
easily. So I can say for sure there at there are scripts out there
that depend on /proc/slabinfo, but they generally tend to be at sites
where people won't be running bleeding edge kernels.
I have a general problem with things in /sys/slab, and that's just
because they are *ugly*. So yes, you can write ugly shell scripts
like this to get out information:
But sometimes when trying to eyeball what is going on, it's a lot
nicer just to use "cat /proc/slabinfo".
Another problem with using /sys/slab is that it is downright *ugly*.
Why is it for example, that /sys/slab/dentry is a symlink to
../slab/:a-0000160? Because of this, Linus's script reports dentry twice:
10942 MB 86 buffer_head
10942 MB 86 journal_head
10943 MB 86 :a-0000056
21923 MB 86 dentry
21924 MB 86 :a-0000160
78437 MB 94 ext3_inode_cache
Once as "dentry" and once as ":a-0000160". A similar situation
happens with journal_head and ":a-0000056". I'm sure this could be
filtered out with the right shell or perl script, but now we're
getting even farther from /proc/slabinfo.
Further, if you look at Documentation/sysfs-rules.txt (does anyone
ever read it or bother to update it?), /sys/slab isn't documented so
it falls in the category of "everything else is a kernel-level
implementation detail which is not guaranteed to be stable". Nice....
Also, looking at sysfs-rules.txt, it talks an awful lot about reading
symlinks, and implying that actually trying to *dereference* the
symlinks might not actually work. So I'm pretty sure linus's "cd
/sys/slab; for i in *" violates the Documentation/sysfs-rules.txt
guidelines even if /sys/slab were documented.
In general, /sys has some real issues that need some careful scrutiny.
Documentation/sysfs-rules.txt is *not* enough. For example, various
official websites are telling people that the way to enable or disable
power-saving is:
echo 5 > /sys/bus/pci/drivers/iwl4965/*/power_level
(Reference: http://www.lesswatts.org/tips/wireless.php)
Aside from the fact that "iwconfig wlan0 power on" is easier to type
and simpler to undrestand, I'm pretty sure that the above violates
sysfs-rules.txt. From looking at sysfs-rules.txt, the fact that you
have to read symlinks as the only valid and guaranteed way for things
to work means that you have to write a perl script to safely
manipulate things in /sys. People are ignoring sysfs-rules.txt, and
giving advice in websites contrary to sysfs-rules.txt because it's too
hard to follow.
And that's another problem with trying to use /sys when trying to get
statistics in bulk... Very often the tables in /proc/* were not only
more convenient, but allowed for atomic access.
- Ted
--
