From: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
To: Andi Kleen <ak@suse.de>
Cc: Hugh Dickins <hugh@veritas.com>,
Christoph Lameter <clameter@sgi.com>,
linux-mm@kvack.org, Zoltan.Menyhart@free.fr
Subject: Re: RFC: RCU protected page table walking
Date: Thu, 04 May 2006 13:32:51 +0200 [thread overview]
Message-ID: <4459E663.10008@bull.net> (raw)
In-Reply-To: <200605041131.46254.ak@suse.de>
Andi Kleen wrote:
> We don't free the pages until the other CPUs have been flushed synchronously.
Do you mean the TLB entries mapping the leaf pages?
If yes, then I agree with you about them.
Yet I speak about the directory pages. Let's take an example:
Assume:
- A process with 2 threads, bound to their respective CPUs
- One of them mapped a file and
this mapping requires a new PMD and a new PTE page
- They read in some data pages
- Time goes by without ever touching any of these pages again
- The swapped removes the data pages (data flush, TLB purge)
- (on IA64: due to the TLB pressure, the TLB entry mapping the PTE page
gets killed)
There is no valid TLB entry concerning this mapped zone any more => the TLB
purges around "free_pgtables()" can be considered as NO-OP-s.
(In addition, walking the page tables in physical mode is insensitive to any
TLB purges.)
CPU #1 faults on attempting to touch this mapped zone.
CPU #1 starts to walk the page tables in physical mode.
Assume it has got the address of the PMD page, it is about to fetch "pmd[j]".
CPU #2 executes "free_pgtables()" in the mean time: it sets free the PTE and
the PGD pages (without knowing that CPU #1 has already got a PMD pointer).
Someone else allocates these two pages and fills them in with some data.
CPU #1 now fetches "pmd[j]" from a page of someone else. Without noticing
anything, CPU #1 uses the illegal value to continue to access the PTE page.
> After the flush the other CPUs don't walk pages anymore.
Can you explain please why they do not?
There is a possibility that walking has already been started, but it has
not been completed yet, when "free_pgtables()" runs.
> The whole thing is
> batched because the synchronous flush can be pretty expensive.
Walking the page tables in physical mode is insensitive to any TLB purges,
therefore these purges do not make sure that there is no other CPU just
in the middle of page table walking.
I do a similar batching of the pages to be set free.
The RCU mechanism makes sure that these pages will not be freed before
the already started page table walkers finish their job.
Thanks,
Zoltan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-05-04 11:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-03 15:31 Zoltan Menyhart
2006-05-03 16:46 ` Andi Kleen
2006-05-03 18:00 ` Hugh Dickins
2006-05-03 23:54 ` Christoph Lameter
2006-05-04 2:51 ` Chen, Kenneth W
2006-05-04 4:28 ` Hugh Dickins
2006-05-04 9:26 ` Zoltan Menyhart
2006-05-04 9:31 ` Andi Kleen
2006-05-04 11:32 ` Zoltan Menyhart [this message]
2006-05-04 12:00 ` Andi Kleen
2006-05-04 13:13 ` Robin Holt
2006-05-04 13:54 ` Zoltan Menyhart
2006-05-04 15:27 ` Hugh Dickins
2006-05-04 9:19 ` Zoltan Menyhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4459E663.10008@bull.net \
--to=zoltan.menyhart@bull.net \
--cc=Zoltan.Menyhart@free.fr \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox