linux-kernel - Re: [RFC] Slab allocators: Drop support for destructors

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: <20070510195840.GN19966@holomorphy.com>
Date:	Thu, 10 May 2007 12:58:40 -0700
From:	William Lee Irwin III <wli@...omorphy.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [RFC] Slab allocators: Drop support for destructors

On 5/10/07, Christoph Lameter <clameter@....com> wrote:
>> Or are there valid reason to keep them around? It seems they were mainly
>> used for list management which required them to take a spinlock. Taking a
>> spinlock in a destructor is a bit risky since the slab allocators may run
>> the destructors anytime they decide a slab is no longer needed.
>> Or do we want to continue support destructors? If so why?

On Thu, May 10, 2007 at 10:21:08PM +0300, Pekka Enberg wrote:
> Well, constructors are on their way out too because they don't seem to
> give the performance benefit they were designed for anymore. As for
> destructors, they have been pretty useless in Linux for a long time
> now and we really don't do much "complex initialization" that requires
> undo (releasing resources).

The anti-constructor trend is counterproductive. The cache effects are
not being properly monitored and people are failing to understand the
importance of conserving cache.

Microbenchmarks where you pound the potentially preconstructed data
structures like wild monkeys are not why constructors are used. They're
to avoid burning cachelines in the cases where you need the cache for
other purposes besides building up and tearing down the structures in
question. Data structure layout becomes relevant to this; the
preconstructed cachelines need to be separated from ones that must be
clobbered regardless immediately after allocation. The effect is
cumulative and broadly dispersed. The constructor elimination patches
are incrementally filling up caches with the formerly preconstructed
objects' cachelines, where the degradation from each individual change
is so small as to be difficult to to discern or potentially even seen
to be advantageous on unrealistic microbenchmarks. The net effect of
removing constructors altogether will be degradations in real-world
workloads on account of the combined effect of the cache footprint
increases. The cache should rather be saved for userspace.

What would make this easier to see would be cache instrumentation not
available to most people. Specifically, tabulating what the various
cachelines in the cache are caching. Simulators may be useful to help
determine all that.

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