Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763686AbZD3QX3 (ORCPT ); Thu, 30 Apr 2009 12:23:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761570AbZD3QXT (ORCPT ); Thu, 30 Apr 2009 12:23:19 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:40824 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761552AbZD3QXT (ORCPT ); Thu, 30 Apr 2009 12:23:19 -0400 Date: Thu, 30 Apr 2009 09:13:44 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Ingo Molnar cc: Christoph Lameter , Mathieu Desnoyers , Andrew Morton , Nick Piggin , KOSAKI Motohiro , Peter Zijlstra , thomas.pi@arcor.dea, Yuriy Lalym , Linux Kernel Mailing List , ltt-dev@lists.casi.polymtl.ca, Tejun Heo Subject: Re: [PATCH] Fix dirty page accounting in redirty_page_for_writepage() In-Reply-To: <20090430154255.GA3714@elte.hu> Message-ID: References: <20090430024303.GB19875@Krystal> <20090430133859.GB8329@elte.hu> <20090430141446.GD14696@elte.hu> <20090430143819.GF14696@elte.hu> <20090430150142.GC20580@elte.hu> <20090430154255.GA3714@elte.hu> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1822 Lines: 40 On Thu, 30 Apr 2009, Ingo Molnar wrote: > > nice. Do these all get called with irqs off, all the time? There are lots of non-irq-off cases where non-atomic counters are safe. A couple of reasons: - counters that just don't care enough. Some statistics are very important to always be exact, others are "helpful" but performance is more important than being exactly right. - counters simply not accessed (or at least changed) from interrupts at all. This is very common for some cases, notably "user event" stats. They may need preemption support, but nothing fancier. - counters that are "idempotent" wrt interrupts. For example, anything that will always count up and then down again in a paired fashion (think kernel lock counter, preemption counter etc) is inherently safe as a per-cpu counter without needing any protection at all, since any interrupts may _change_ them, but will always change them back, so even if a non-atomic sequence gets interrupted, it doesn't matter. In fact, I'd argue that for a per-cpu counter, the whole _point_ of the exercise is almost always performance, so locked sequences would be bad to assume. The fact that x86 can do "atomic" per-cpu accesses with basically zero cost (by virtue of it's rmw memory ops) is unusual. Most other architectures will have a very hard time making such counters cheap, since for them, there "irq atomicity" (expensive irq disable or store conditional) or "SMP atomicity" (the same fairly expensive store-conditional or something even worse). Linus -- 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/