Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964849AbWL1AwW (ORCPT ); Wed, 27 Dec 2006 19:52:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964842AbWL1AwW (ORCPT ); Wed, 27 Dec 2006 19:52:22 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:59157 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S964834AbWL1AwW (ORCPT ); Wed, 27 Dec 2006 19:52:22 -0500 Date: Wed, 27 Dec 2006 16:52:21 -0800 (PST) Message-Id: <20061227.165221.55508787.davem@davemloft.net> To: torvalds@osdl.org Cc: schwidefsky@de.ibm.com, a.p.zijlstra@chello.nl, tbm@cyrius.com, hugh@veritas.com, nickpiggin@yahoo.com.au, arjan@infradead.org, andrei.popa@i-neo.ro, akpm@osdl.org, linux-kernel@vger.kernel.org, fw@deneb.enyo.de, mh+linux-kernel@zugschlus.de, heiko.carstens@de.ibm.com, arnd.bergmann@de.ibm.com, gordonfarquharson@gmail.com Subject: Re: [PATCH] mm: fix page_mkclean_one From: David Miller In-Reply-To: References: <1167264000.5200.21.camel@localhost> X-Mailer: Mew version 5.1.52 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1191 Lines: 27 From: Linus Torvalds Date: Wed, 27 Dec 2006 16:42:40 -0800 (PST) > That's fine. In that situation, you shouldn't need any atomic ops at all, > I think all our sw page-table operations are already done under the pte > lock. This is true, but there is one subtlety to this I want to point out in passing. That lock can possibly only protect a page of PTEs. When NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS, the locking is done per page of PTEs, not for all of the page tables of an address space at once. What this means is that it's really difficult to forcefully block out all page table operations for a given mm, and I actually needed to do something like this on sparc64 (when growing the TLB lookup hash table, you can't let any PTEs change state while the table is changing). For my case, I added a spinlock to mm->context since actually what I need is to block modifications to the hash table itself during PTE changes. - 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/