[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150202223851.f30768d0.akpm@linux-foundation.org>
Date: Mon, 2 Feb 2015 22:38:51 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: "Wang, Yalin" <Yalin.Wang@...ymobile.com>
Cc: "'Kirill A. Shutemov'" <kirill@...temov.name>,
"'arnd@...db.de'" <arnd@...db.de>,
"'linux-arch@...r.kernel.org'" <linux-arch@...r.kernel.org>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
"'linux@....linux.org.uk'" <linux@....linux.org.uk>,
"'linux-arm-kernel@...ts.infradead.org'"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC] change non-atomic bitops method
On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin" <Yalin.Wang@...ymobile.com> wrote:
>
> ...
>
> #ifdef CHECK_BEFORE_SET
> if (p[i] != times)
> #endif
>
> ...
>
> ----
> One run on CPU0, reader thread run on CPU1,
> Test result:
> sudo ./cache_test
> reader:8.426228173
> 8.672198335
>
> With -DCHECK_BEFORE_SET
> sudo ./cache_test_check
> reader:7.537036819
> 10.799746531
>
You aren't measuring the right thing. You should compare
if (p[i] != x)
p[i] = x;
versus
p[i] = x;
and you should do this for two cases:
a) p[i] == x
b) p[i] != x
The first code sequence will be slower when (p[i] != x) and faster when
(p[i] == x).
Next, we should instrument the kernel to work out the frequency of
set_bit on an already-set bit.
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.
--
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/
Powered by blists - more mailing lists