linux-kernel - Re: Major regression on hackbench with SLUB (more numbers)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 22 Dec 2007 11:03:26 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Christoph Lameter <clameter@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: Major regression on hackbench with SLUB (more numbers)

* Andi Kleen <andi@...stfloor.org> wrote:

> Ingo Molnar <mingo@...e.hu> writes:
> 
> > Christoph, /proc/slabinfo is an _ABI_. You HAVE to provide it. 
> > slabtop relies on it, people use it every day to monitor memory 
> > consumption.
> 
> It's definitely not a stable ABI. slabtop tends to exit without any 
> error message on any slabinfo version number increase and I've seen 
> that happen several times in not so old kernels.

so because we sucked in the past we can continue to suck? ;)

Why are we still arguing about this? We kernel developers are foxes 
amongst the hens and if a compatibility issue comes up we have to act 
_doubly_ conservatively.

You think it's reasonable to not offer /proc/slabinfo? You can fairly 
assume that a user considers it absolutely unreasonable. If other kernel 
developers tell you: "no, it's fine", then it's as if other foxes told 
you "no, it's fine to eat that hen, we do it all the time too!" ;-)

> Requiring just another slabtop update isn't really a big deal.

certainly. But consider this from the user's perspective who tries one 
of our devel kernels. He suspects a memory leak. Runs slabtop and 
gets:

 $ slabtop
 fopen /proc/slabinfo: No such file or directory

and would fairly conclude: "ok, this new Linux kernel looks quite 
apparently unfinished, i'm outta here".

We do this way too frequently and many silly details like this _do_ 
mount up.

> Also it's not that it's a critical functionality like udev.

Sure, we can argue about details that not all fields in /proc/slabinfo 
are relevant, and that slabtop should be a bit more careful, etc., but 
we've got what we've got because _we_ built the current code, so we 
might as well accept the consequences it brings. The most of the basic 
output of slabtop:

 Active / Total Objects (% used)    : 648754 / 747076 (86.8%)
 Active / Total Slabs (% used)      : 39394 / 39394 (100.0%)
 Active / Total Caches (% used)     : 103 / 143 (72.0%)
 Active / Total Size (% used)       : 138884.36K / 151075.96K (91.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.20K / 128.00K

   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 261928 239808  91%    0.13K   9032       29     36128K dentry_cache
 222048 174144  78%    0.05K   3084       72     12336K buffer_head
 187232 178929  95%    0.48K  23404        8     93616K ext3_inode_cache
  24416  17908  73%    0.27K   1744       14      6976K radix_tree_node

could be offered on SLUB too.

'top' isnt critical functionality either like udev, and the ABI does not 
only cover 'critical' functionality. A utility suddenly not working 
gives Linux a pretty amateurish feeling. Should we tell users/admins: 
"Hehe, gotcha! Didnt you know /proc/slabinfo was not an ABI? Poor sob. 
If you want your stuff to continue working, use Windows next time around 
or what. Sheesh, what do these people want!' ;-)

the rule is very simple: unless you have really, really, really, REALLY 
good reasons, just dont break stuff.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/