From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
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: Mon, 15 Dec 2008 17:28:19 -0800 [thread overview]
Message-ID: <49470433.4050504@goop.org> (raw)
In-Reply-To: <200707241140.12945.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
> On Friday 12 December 2008 12:59, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> 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?
>>>
>> No. Well, yes, it would, but Xen itself will do whatever tlb flushes
>> are necessary to keep it safe (it must, since it doesn't trust guest
>> kernels). It's fairly clever about working out which cpus need flushing
>> and if other flushes have already done the job.
>>
>
> OK. Yeah, then the problem is simply that the guest may reuse that virtual
> memory for another vmap.
>
Hm. What you would you think of a "deferred tlb flush" flag (or
something) to cause the next vmap to do the tlb flushes, in the case the
vunmap happens in a context where the flushes can't be done?
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Nick Piggin <nickpiggin@yahoo.com.au>
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: Mon, 15 Dec 2008 17:28:19 -0800 [thread overview]
Message-ID: <49470433.4050504@goop.org> (raw)
In-Reply-To: <200707241140.12945.nickpiggin@yahoo.com.au>
Nick Piggin wrote:
> On Friday 12 December 2008 12:59, Jeremy Fitzhardinge wrote:
>
>> Nick Piggin wrote:
>>
>>> 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?
>>>
>> No. Well, yes, it would, but Xen itself will do whatever tlb flushes
>> are necessary to keep it safe (it must, since it doesn't trust guest
>> kernels). It's fairly clever about working out which cpus need flushing
>> and if other flushes have already done the job.
>>
>
> OK. Yeah, then the problem is simply that the guest may reuse that virtual
> memory for another vmap.
>
Hm. What you would you think of a "deferred tlb flush" flag (or
something) to cause the next vmap to do the tlb flushes, in the case the
vunmap happens in a context where the flushes can't be done?
J
--
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:[~2008-12-16 1:28 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-11 19:05 [PATCH RFC] vm_unmap_aliases: allow callers to inhibit TLB flush Jeremy Fitzhardinge
2007-07-24 0:52 ` Nick Piggin
2008-12-12 1:59 ` Jeremy Fitzhardinge
2007-07-24 1:40 ` Nick Piggin
2008-12-16 1:28 ` Jeremy Fitzhardinge [this message]
2008-12-16 1:28 ` Jeremy Fitzhardinge
2008-12-30 3:42 ` Nick Piggin
2008-12-30 3:42 ` Nick Piggin
2008-12-30 11:27 ` Jeremy Fitzhardinge
2008-12-30 11:27 ` Jeremy Fitzhardinge
2009-02-17 21:57 ` Jeremy Fitzhardinge
2009-02-17 21:57 ` Jeremy Fitzhardinge
2009-02-19 11:54 ` Nick Piggin
2009-02-19 11:54 ` Nick Piggin
2009-02-19 17:02 ` Jeremy Fitzhardinge
2009-02-19 17:02 ` Jeremy Fitzhardinge
2009-02-19 17:41 ` Nick Piggin
2009-02-19 17:41 ` Nick Piggin
2009-02-19 19:11 ` Jeremy Fitzhardinge
2009-02-19 19:11 ` Jeremy Fitzhardinge
2009-02-23 4:14 ` Nick Piggin
2009-02-23 4:14 ` Nick Piggin
2009-02-23 7:30 ` Jeremy Fitzhardinge
2009-02-23 7:30 ` Jeremy Fitzhardinge
2009-02-23 9:13 ` Nick Piggin
2009-02-23 9:13 ` Nick Piggin
2009-02-23 19:27 ` Jeremy Fitzhardinge
2009-02-23 19:27 ` Jeremy Fitzhardinge
2009-02-24 12:23 ` Nick Piggin
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=49470433.4050504@goop.org \
--to=jeremy@goop.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
--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 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.