Re: [Patch 3/3] prepopulate/cache cleared pages
From: Nick Piggin
Date: Fri Feb 24 2006 - 01:59:28 EST
Ingo Molnar wrote:
* Nick Piggin <nickpiggin@xxxxxxxxxxxx> wrote:
couldnt the new pte be flipped in atomically via cmpxchg? That way
we could do the page clearing close to where we are doing it now,
but without holding the mmap_sem.
We have nothing to pin the pte page with if we're not holding the
mmap_sem.
why does it have to be pinned? The page is mostly private to this thread
until it manages to flip it into the pte. Since there's no pte presence,
there's no swapout possible [here i'm assuming anonymous malloc()
memory, which is the main focus of Arjan's patch]. Any parallel
unmapping of that page will be caught and the installation of the page
will be prevented by the 'bit-spin-lock' embedded in the pte.
No, I was talking about page table pages, rather than the newly
allocated page.
But I didn't realise you wanted the bit lock to go the other way
as well (ie. a real bit spinlock). Seems like that would have to
add overhead somewhere.
But even in that case, there is nothing in the mmu gather / tlb flush
interface that guarantees an architecture cannot free the page table
pages immediately (ie without waiting for the flush IPI). This would
make sense on architectures that don't walk the page tables in
hardware.
but the page wont be found by any other CPU, so it wont be freed! It is
private to this CPU. The page has no pte presence. It will only be
present and lookupable as a result of the cmpxchg() flipping the page
into the pte.
Yeah, as I said above, the newly allocated page is fine, it is the
page table pages I'm worried about.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/