Thread (20 messages) 20 messages, 8 authors, 2015-02-10

[RFC] change non-atomic bitops method

From: akpm@linux-foundation.org (Andrew Morton)
Date: 2015-02-03 08:49:12
Also in: linux-arch, lkml

On Tue, 03 Feb 2015 00:40:31 -0800 (PST) David Miller [off-list ref] wrote:
From: Andrew Morton <akpm@linux-foundation.org>
Date: Mon, 2 Feb 2015 22:38:51 -0800
quoted
It is only with both these ratios that we can work out whether the
patch is a net gain.  My suspicion is that set_bit on an already-set
bit is so rare that the patch will be a loss.
A common pattern is implementing a "referenced" bit, and in that case
the bit is often already set, and in such a scenerio the proposed
change is a huge win.
pagecache, dcache and icache already perform this optimisation (and
only pagecache uses bitops for it anyway).  I'm not sure what's left.

But there's really no point in speculating about this - it's trivial to
instrument the kernel and get real numbers.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help