From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
the arch/x86 maintainers <x86@kernel.org>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush
Date: Tue, 24 Jul 2007 10:52:13 +1000 [thread overview]
Message-ID: <200707241052.13825.nickpiggin@yahoo.com.au> (raw)
In-Reply-To: <49416494.6040009@goop.org>
Hi,
On Friday 12 December 2008 06:05, Jeremy Fitzhardinge wrote:
> Hi Nick,
>
> In Xen when we're killing the lazy vmalloc aliases, we're only concerned
> about the pagetable references to the mapped pages, not the TLB entries.
Hm? Why is that? Why wouldn't it matter if some page table page gets
written to via a stale TLB?
> For the most part eliminating the TLB flushes would be a performance
> optimisation, but there's at least one case where we need to shoot down
> aliases in an interrupt-disabled section, so the TLB shootdown IPIs
> would potentially deadlock.
So... 2.6.28 is deadlocky for you?
> I'm wondering what your thoughts are about this approach?
Doesn't work, because that's allowing virtual addresses to be reused
before they have TLBs flushed.
You could have a xen specific function which goes through the lazy maps
and unmaps their page tables, but leaves them in the virtual address
allocator (so a subsequent lazy flush will still do the TLB flush before
allowing the addresses to be reused).
> I'm not super-happy with the changes to __purge_vmap_area_lazy(), but
> given that we need a tri-state policy selection there, adding an enum is
> clearer than adding another boolean argument.
>
> It also raises the question of how many callers of vm_unmap_aliases()
> really care about flushing the tlbs. Presumably if we're shooting down
> some stray vmalloc mappings then nobody is actually using them at the
> time, and any corresponding TLB entries are residual. Or does leaving
> them around leave open the possibility of unwanted speculative
> references which could violate memory type rules? Perhaps callers who
> care about that could arrange their own tlb flush?
The whole lazy flush requires the TLB flush because the core vmalloc
code needs to flush before reallocating. So it can't really go into
the caller.
PAT needs the TLBs flushed, definitely.
I'm surprised that Xen doesn't... but let's hear it :)
next prev parent reply other threads:[~2007-07-24 0:52 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 19:05 Jeremy Fitzhardinge
2007-07-24 0:52 ` Nick Piggin [this message]
2008-12-12 1:59 ` Jeremy Fitzhardinge
2007-07-24 1:40 ` Nick Piggin
2008-12-16 1:28 ` Jeremy Fitzhardinge
2008-12-30 3:42 ` Nick Piggin
2008-12-30 11:27 ` Jeremy Fitzhardinge
2009-02-17 21:57 ` Jeremy Fitzhardinge
2009-02-19 11:54 ` Nick Piggin
2009-02-19 17:02 ` Jeremy Fitzhardinge
2009-02-19 17:41 ` Nick Piggin
2009-02-19 19:11 ` Jeremy Fitzhardinge
2009-02-23 4:14 ` Nick Piggin
2009-02-23 7:30 ` Jeremy Fitzhardinge
2009-02-23 9:13 ` Nick Piggin
2009-02-23 19:27 ` Jeremy Fitzhardinge
2009-02-24 12:23 ` Nick Piggin
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=200707241052.13825.nickpiggin@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=x86@kernel.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