> -----Original Message----- > From: Andrew Morton [mailto:akpm@xxxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, February 03, 2015 2:39 PM > To: Wang, Yalin > Cc: 'Kirill A. Shutemov'; 'arnd@xxxxxxxx'; 'linux-arch@xxxxxxxxxxxxxxx'; > 'linux-kernel@xxxxxxxxxxxxxxx'; 'linux@xxxxxxxxxxxxxxxx'; 'linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx' > Subject: Re: [RFC] change non-atomic bitops method > > On Tue, 3 Feb 2015 13:42:45 +0800 "Wang, Yalin" <Yalin.Wang@xxxxxxxxxxxxxx> > 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. 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
