Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754497AbbBCJeN (ORCPT ); Tue, 3 Feb 2015 04:34:13 -0500 Received: from mail-la0-f53.google.com ([209.85.215.53]:62647 "EHLO mail-la0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750798AbbBCJeJ (ORCPT ); Tue, 3 Feb 2015 04:34:09 -0500 From: Rasmus Villemoes To: Andrew Morton Cc: "Wang\, Yalin" , "'Kirill A. Shutemov'" , "'arnd\@arndb.de'" , "'linux-arch\@vger.kernel.org'" , "'linux-kernel\@vger.kernel.org'" , "'linux\@arm.linux.org.uk'" , "'linux-arm-kernel\@lists.infradead.org'" Subject: Re: [RFC] change non-atomic bitops method Organization: D03 References: <35FD53F367049845BC99AC72306C23D1044A02027E0A@CNBJMBX05.corpusers.net> <20150202152909.13bfd11f192fb0268b2ab4bf@linux-foundation.org> <20150203011730.GA15653@node.dhcp.inet.fi> <35FD53F367049845BC99AC72306C23D1044A02027E0B@CNBJMBX05.corpusers.net> <35FD53F367049845BC99AC72306C23D1044A02027E0C@CNBJMBX05.corpusers.net> <20150202223851.f30768d0.akpm@linux-foundation.org> X-Hashcash: 1:20:150203:linux@arm.linux.org.uk::5CsLVnFGSVb4JOUz:0000000000000000000000000000000000000000jPj X-Hashcash: 1:20:150203:linux-kernel@vger.kernel.org::67dB21WDoZVg46Hl:0000000000000000000000000000000000vqn X-Hashcash: 1:20:150203:linux-arch@vger.kernel.org::wIg/7fLZOYp47XZb:000000000000000000000000000000000002nGG X-Hashcash: 1:20:150203:yalin.wang@sonymobile.com::Wvcbzf3KfC/l/wMV:00000000000000000000000000000000000033Ax X-Hashcash: 1:20:150203:akpm@linux-foundation.org::Tn/KKmiall0UVkMS:0000000000000000000000000000000000003Fnq X-Hashcash: 1:20:150203:linux-arm-kernel@lists.infradead.org::jqDlhZAZ0RduROal:00000000000000000000000006WPP X-Hashcash: 1:20:150203:arnd@arndb.de::t78g6fziJPlPqoMx:00009D+I X-Hashcash: 1:20:150203:kirill@shutemov.name::4BEYbxBnwK8UlA2E:00000000000000000000000000000000000000000A7iE Date: Tue, 03 Feb 2015 10:34:05 +0100 In-Reply-To: <20150202223851.f30768d0.akpm@linux-foundation.org> (Andrew Morton's message of "Mon, 2 Feb 2015 22:38:51 -0800") Message-ID: <8761bjjq42.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1621 Lines: 49 On Tue, Feb 03 2015, Andrew Morton wrote: > > 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. There's also the code-bloat issue to consider (instruction cache and all that); the conditional versions will usually require three extra instructions and an extra register. Also, the cache line might already be dirty because of something in the surrounding code. Instruction cache misses and larger stack footprint (from larger register pressure) won't show up in a microbenchmark, so I think this needs a real-world example to justify. But even if one finds some hot spot that would benefit from the conditional, that should simply be added explicitly there, instead of pessimizing every other user. (A good example of that is 358eec18243a ("vfs: decrapify dput(), fix cache behavior under normal load")). Rasmus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/