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]

Message-ID: <alpine.LFD.0.9999.0712220937560.21557@woody.linux-foundation.org>
Date:	Sat, 22 Dec 2007 10:01:37 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Andi Kleen <andi@...stfloor.org>,
	Christoph Lameter <clameter@....com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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)

On Sat, 22 Dec 2007, Ingo Molnar wrote:
> > 
> > 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? ;)

Well, I do have to admit that I'm not a huge fan of /proc/slabinfo, and 
the fact that there hasn't been a lot of complaints about it going away 
does seem to imply that it wasn't a very important ABI.

I'm the first to stand up for backwards compatibility, but I also try to 
be realistic, and so far nobody has really complained about the fact that 
/proc/slabinfo went away on any grounds but on the general principle of 
"it was a user-visible ABI".

We've changed user-visible ABI's in the past in the hope that they weren't 
actually used. Sometimes it worked, sometimes it didn't. In this case, I 
think it still has the potential of working.

That said, I'm not a *huge* fan of /sys/slab/ either. I can get the info I 
as a developer tend to want from there, but it's really rather less 
convenient than I'd like. It is really quite hard, for example, to get any 
kind of "who actually uses the most *memory*" information out of there. 

You have to use something like this:

	for i in *
	do
		order=$(cat "$i/order")
		slabs=$(cat "$i/slabs")
		object_size=$(cat "$i/object_size")
		objects=$(cat "$i/objects")
		truesize=$(( $slabs<<($order+12) ))
		size=$(( $object_size*$objects ))
		percent=$(( $truesize/100 ))
		if [ $percent -gt 0 ]; then
			percent=$(( $size / $percent ))
		fi
		mb=$(( $size >> 10 ))
		printf "%10d MB %3d %s\n" $mb $percent $i
	done | sort -n | tail

which works fine, but while it's actually _much_ more readable than doing 
the same thing with /proc/slabinfo was, I worry about the lack of 
atomicity in getting the statistics.

I dunno. I do think /sys/slab/ is a better interface than /proc/slabinfo 
was. I just wonder if it could be better still.

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