All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Zoltan Menyhart <Zoltan.Menyhart@bull.net>
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, 4 May 2006 14:00:34 +0200	[thread overview]
Message-ID: <200605041400.34851.ak@suse.de> (raw)
In-Reply-To: <4459E663.10008@bull.net>

On Thursday 04 May 2006 13:32, Zoltan Menyhart wrote:
> 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:

x86 uses this for the directory pages too (well for PMD/PUD - PGD never
goes away until final exit). Actually x86-64 didn't
fully at some point and it resulted in a nasty to track down bug.
But it was fixed then. I really went all over this with a very fine
comb back then and I'm pretty sure it's correct now :)

> > After the flush the other CPUs don't walk pages anymore.
> 
> Can you explain please why they do not?

Because the PGD/PMD/PUD has been rewritten and they won't be able
to find the old pages anymore. They also don't have it in their
TLBs because that has been flushed.

The problem I had on x86-64 was because visible the AMD CPUs internally cached
PMD/PGDs.

> There is a possibility that walking has already been started, but it has
> not been completed yet, when "free_pgtables()" runs.
>

Yes, that is why we delay the freeing of the pages to prevent anything
going wrong.

> > The whole thing is
> > batched because the synchronous flush can be pretty expensive.
> 
> Walking the page tables in physical mode 

What do you mean with "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.

A TLB Flush stops all MMU activity - or rather waits for it to finish.

-Andi

--
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>

  reply	other threads:[~2006-05-04 12:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-03 15:31 RFC: RCU protected page table walking 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-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
2006-05-04 12:00           ` Andi Kleen [this message]
2006-05-04 13:13             ` Robin Holt
2006-05-04 13:54             ` Zoltan Menyhart
2006-05-04 15:27               ` Hugh Dickins
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=200605041400.34851.ak@suse.de \
    --to=ak@suse.de \
    --cc=Zoltan.Menyhart@bull.net \
    --cc=Zoltan.Menyhart@free.fr \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.