[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <113623.1410326115@turing-police.cc.vt.edu>
Date: Wed, 10 Sep 2014 01:15:15 -0400
From: Valdis.Kletnieks@...edu
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Jiri Kosina <jkosina@...e.cz>, Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Dan Carpenter <dan.carpenter@...cle.com>,
"Theodore Ts'o" <tytso@....edu>
Subject: Re: [PATCH] mm/sl[aou]b: make kfree() aware of error pointers
On Tue, 09 Sep 2014 16:21:14 -0700, Andrew Morton said:
> On Tue, 9 Sep 2014 23:25:28 +0200 (CEST) Jiri Kosina <jkosina@...e.cz> wrote:
> kfree() is quite a hot path to which this will add overhead. And we
> have (as far as we know) no code which will actually use this at
> present.
We already do a check for ZERO_SIZE_PTR, and given that dereferencing *that* is
instant death for the kernel, and we see it very rarely, I'm going to guess
that IS_ERR(ptr) *has* to be true more often than ZERO_SIZE_PTR, and thus even
more advantageous to short-circuit.
I guess it depends on a few things:
1) How many instances of 'if (!IS_ERR(foo)) kfree(foo);' are in the tree, and
what percent of kfree() calls executed have the guard on them
2) How many of the hot calls can/will get the guard removed.
3) How many cycles, if any, this adds to the path (a non-trivial question on
superscalar architectures), compared with doing a test before calling kfree()
I unfortunately have no earthly clue what the values of any of those
three quantities are....
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists