[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061227.165221.55508787.davem@davemloft.net>
Date: Wed, 27 Dec 2006 16:52:21 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: torvalds@...l.org
Cc: schwidefsky@...ibm.com, a.p.zijlstra@...llo.nl, tbm@...ius.com,
hugh@...itas.com, nickpiggin@...oo.com.au, arjan@...radead.org,
andrei.popa@...eo.ro, akpm@...l.org, linux-kernel@...r.kernel.org,
fw@...eb.enyo.de, mh+linux-kernel@...schlus.de,
heiko.carstens@...ibm.com, arnd.bergmann@...ibm.com,
gordonfarquharson@...il.com
Subject: Re: [PATCH] mm: fix page_mkclean_one
From: Linus Torvalds <torvalds@...l.org>
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists