linux-kernel - Re: [PATCH 4/4] sl[au]b: process slabinfo

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 for Android: free password hash cracker in your pocket

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

Message-ID: <0000013a08dd105c-06e1ed72-defd-4e0e-aee6-89f6244328f0-000000@email.amazonses.com>
Date:	Thu, 27 Sep 2012 17:53:57 +0000
From:	Christoph Lameter <cl@...ux.com>
To:	Glauber Costa <glommer@...allels.com>
cc:	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [PATCH 4/4] sl[au]b: process slabinfo_show in common code

On Thu, 27 Sep 2012, Glauber Costa wrote:

> Yes. As a matter of fact, I first implemented it this way, and later
> switched. I was anticipating that people would be likely to point out
> that those properties are directly derivable from the caches, and it
> would be better to just get them from there.

That is not the case if the information is packet as in the case of SLUB.

SLOB (which at some point also could be supported) has an altogether
different way of arranging objects in pagbes.


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