From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Hugh Dickins <hugh@veritas.com>,
linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
Nick Piggin <npiggin@suse.de>,
"David S. Miller" <davem@davemloft.net>,
Zach Amsden <zach@vmware.com>,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: tlb_gather_mmu() and semantics of "fullmm"
Date: Fri, 27 Mar 2009 10:13:02 +1100 [thread overview]
Message-ID: <1238109182.16498.47.camel@pasglop> (raw)
In-Reply-To: <alpine.LFD.2.00.0903260927320.3032@localhost.localdomain>
> Side note: this means that CPU's that do speculative TLB fills may still
> touch the user entries.
Ok. That's what I wasn't sure of. It's fortunately not the case on SW
loaded TLBs so I may still do some optimisations on these guys.
> They won't _care_ about what they get, though. So
> you should be able to do any optimizations you want, as long as it doesn't
> cause machine checks or similar (ie another CPU doing a speculative access
> and then being really unhappy about a totally invalid page table entry).
Right.
> > Although it looks as if there's a TLB flush at the end of every batch,
> > isn't that deceptive (on x86 anyway)?
>
> You need to. Again. Even on that CPU the TLB may have gotten re-loaded
> speculatively, even if nothing _meant_ to touch user pages.
>
> So you can't just flush the TLB once, and then expect that since you
> flushed it, and nothing else accessed those user addresses, you don't need
> to flush it again.
>
> And doing things the other way around - only flushing once at the end - is
> incorrect because the whole point is that we can only free the page
> directory once we've flushed all the translations that used it. So we need
> to flush before the real release, and we need to flush after we've
> unmapped everything. Thus the repeated flushes.
>
> It shouldn't be that costly, since kernel mappings should be marked
> global.
I was talking about the freeing of the individual pages, not the page
tables per-se, but yes, I see that the problem is there too.
I'll do some experiments on embedded stuffs here and see if it's worth
doing things differently. I'm trying to avoid too many IPIs typically.
The problem with our TLBs is that they cache multiple contexts, and so
they may still hold translations for contexts not currently active,
-but- we really don't need to do heavy synchronisation to flush those.
Cheers,
Ben.
--
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:[~2009-03-27 3:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-26 5:01 Benjamin Herrenschmidt
2009-03-26 14:08 ` Hugh Dickins
2009-03-26 16:38 ` Linus Torvalds
2009-03-26 23:13 ` Benjamin Herrenschmidt [this message]
2009-03-26 17:21 ` Jeremy Fitzhardinge
2009-03-26 20:39 ` David Miller
2009-03-26 22:33 ` Benjamin Herrenschmidt
2009-03-27 5:04 ` David Miller
2009-03-27 5:38 ` Benjamin Herrenschmidt
2009-03-27 5:44 ` David Miller
2009-03-27 5:54 ` Benjamin Herrenschmidt
2009-03-27 5:57 ` David Miller
2009-03-27 6:10 ` Benjamin Herrenschmidt
2009-03-27 8:05 ` David Miller
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=1238109182.16498.47.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=hugh@veritas.com \
--cc=jeremy@goop.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
--cc=torvalds@linux-foundation.org \
--cc=zach@vmware.com \
/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