linux-kernel - Re: [PATCH 08/40] mm: kmem_cache

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: <Pine.LNX.4.64.0705041142350.24625@schroedinger.engr.sgi.com>
Date:	Fri, 4 May 2007 11:46:54 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	netdev@...r.kernel.org,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Thomas Graf <tgraf@...g.ch>,
	David Miller <davem@...emloft.net>,
	James Bottomley <James.Bottomley@...elEye.com>,
	Mike Christie <michaelc@...wisc.edu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Daniel Phillips <phillips@...gle.com>
Subject: Re: [PATCH 08/40] mm: kmem_cache_objsize

On Fri, 4 May 2007, Pekka Enberg wrote:

> > which would calculate the worst case memory scenario for allocation the
> > number of indicated objects?
> 
> IIRC this looks more or less what Peter had initially. I don't like the API
> because there's no way for slab (perhaps this is different for slub) how many
> pages you really need due to per-node and per-cpu caches, etc.

SLAB can calculate exactly how many pages are needed. The per 
cpu and per node stuff is setup at boot and does not change. We are 
talking about the worst case scenario here. True in case of an off slab
we have additional overhead that would also have to go into worst case 
scenario.

> It's better that the slab tells you what it actually knows and lets the
> callers figure out what a worst-case upper bound is.

They do not have the data. For that they would need to know how to deal 
with alignments, (in case of SLAB) the location of the struct slab, the 
distinction between the differrent sizes, padding etc. I think this has to 
be done by the allocator. If we ever have another allocator with another 
structure then this will nicely isolate that functionality. Otherwise we 
may have to change the callers depending on how the slab organizes its 
data.

SLUB organizes its data more effectively so SLUB will return a lower 
number than SLAB f.e.
-
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/