[<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
 
