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

[RFC] change non-atomic bitops method

From: Wang, Yalin <hidden>
Date: 2015-02-03 07:03:48
Also in: linux-arch, lkml

-----Original Message-----
From: Andrew Morton [mailto:akpm at linux-foundation.org]
Sent: Tuesday, February 03, 2015 2:39 PM
To: Wang, Yalin
Cc: 'Kirill A. Shutemov'; 'arnd at arndb.de'; 'linux-arch at vger.kernel.org';
'linux-kernel at vger.kernel.org'; 'linux at arm.linux.org.uk'; 'linux-arm-
kernel at lists.infradead.org'
Subject: Re: [RFC] change non-atomic bitops method

On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin" [off-list ref]
wrote:
quoted
...

#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.
I see, let's change the test a little:
1)
	memset(p, 0, SIZE);
	if (p[i] != 0)
		p[i] = 0;  // never called

	#sudo ./cache_test_check
	6.698153838
	reader:7.529402625


2)
	memset(p, 0, SIZE);
	if (p[i] == 0)
		p[i] = 0; // always called
	#sudo ./cache_test_check
	reader:7.895421311
	9.000889973

Thanks
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help