Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763516AbZD3NtW (ORCPT ); Thu, 30 Apr 2009 09:49:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1763420AbZD3NsS (ORCPT ); Thu, 30 Apr 2009 09:48:18 -0400 Received: from smtp.ultrahosting.com ([74.213.174.254]:50412 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763193AbZD3NsO (ORCPT ); Thu, 30 Apr 2009 09:48:14 -0400 Date: Thu, 30 Apr 2009 09:38:14 -0400 (EDT) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Ingo Molnar cc: Mathieu Desnoyers , Tejun Heo , Nick Piggin , Peter Zijlstra , Yuriy Lalym , Linux Kernel Mailing List , ltt-dev@lists.casi.polymtl.ca, Andrew Morton , thomas.pi@arcor.dea, Linus Torvalds Subject: Re: [ltt-dev] [PATCH] Fix dirty page accounting in redirty_page_for_writepage() In-Reply-To: <20090430065055.GA16277@elte.hu> Message-ID: References: <20090429232546.GB15782@Krystal> <20090430024303.GB19875@Krystal> <20090430062140.GA9559@elte.hu> <20090430063306.GA27431@Krystal> <20090430065055.GA16277@elte.hu> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) 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: 1489 Lines: 37 On Thu, 30 Apr 2009, Ingo Molnar wrote: > > I see however that it's only guaranteed to be atomic wrt preemption. > > That's really only true for the non-x86 fallback defines. If we so > decide, we could make the fallbacks in asm-generic/percpu.h irq-safe The fallbacks have different semantics and therefore we cannot rely on irq safeness in the core code when using the x86 cpu ops. > nmi-safe isnt a big issue (we have no NMI code that interacts with > MM counters) - and we could make them irq-safe by fixing the > wrapper. (and on x86 they are NMI-safe too.) There are also context in which you alrady are preempt safe and where the per cpu ops do not need to go through the prremption hoops. This means it would be best to have 3 variants for 3 different contexts in the core code: 1. Need irq safety 2. Need preempt safety 3. We know the operation is safe due to preemption already having been disabled or irqs are not enabled. The 3 variants on x86 generate the same instructions. On other platforms they would need to be able to fallback in various way depending on the availability of instructions that are atomic vs. preempt or irqs. http://thread.gmane.org/gmane.linux.kernel.cross-arch/1124 http://lwn.net/Articles/284526/ -- 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/