From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Peter Chubb <peterc@gelato.unsw.edu.au>
Cc: linux-mm@kvack.org, Carsten Otte <cotte@de.ibm.com>,
virtualization@lists.linux-foundation.org
Subject: Re: RFC: multiple address spaces for one process
Date: Fri, 29 Jun 2007 10:32:01 -0400 [thread overview]
Message-ID: <468517E1.4050803@goop.org> (raw)
In-Reply-To: <87myynt1m6.wl%peter@chubb.wattle.id.au>
Peter Chubb wrote:
> In a hosted VMM like LinuxOnLinux or UML, context switch time can be a
> major problem (as mmap when repeated for each guest page frame takes a
> long time). One solution is to allow the host kernel to keep a cache of
> address space contexts, and switch between them in a single
> operation.
>
Other VMMs which have a large usermode component, like lguest and kvm,
do maintain two address spaces mapping the same set of pages. But
unlike UML (and I guess LoL), the guest mappings are not represented as
VMAs, but just as a raw processor pagetable. They need some special
switcher code to go into that state, so it doesn't look like this would
be terribly useful for them.
Am I right in presuming that this is really only useful for VMMs which
want to use mmap/mprotect/munmap for the virtual MMU implementation?
It might be interesting if the two cases could be unified in some way,
so that the VMMs could use a common usermode mechanism to achieve the
same end, which is what Carsten was proposing. But its not obvious to
me how much common mechanism can be pulled out, since its a pretty
deeply architecture-specific operation.
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Peter Chubb <peterc@gelato.unsw.edu.au>
Cc: virtualization@lists.linux-foundation.org, linux-mm@kvack.org,
Carsten Otte <cotte@de.ibm.com>, avi Kivity <avi@qumranet.com>
Subject: Re: RFC: multiple address spaces for one process
Date: Fri, 29 Jun 2007 10:32:01 -0400 [thread overview]
Message-ID: <468517E1.4050803@goop.org> (raw)
In-Reply-To: <87myynt1m6.wl%peter@chubb.wattle.id.au>
Peter Chubb wrote:
> In a hosted VMM like LinuxOnLinux or UML, context switch time can be a
> major problem (as mmap when repeated for each guest page frame takes a
> long time). One solution is to allow the host kernel to keep a cache of
> address space contexts, and switch between them in a single
> operation.
>
Other VMMs which have a large usermode component, like lguest and kvm,
do maintain two address spaces mapping the same set of pages. But
unlike UML (and I guess LoL), the guest mappings are not represented as
VMAs, but just as a raw processor pagetable. They need some special
switcher code to go into that state, so it doesn't look like this would
be terribly useful for them.
Am I right in presuming that this is really only useful for VMMs which
want to use mmap/mprotect/munmap for the virtual MMU implementation?
It might be interesting if the two cases could be unified in some way,
so that the VMMs could use a common usermode mechanism to achieve the
same end, which is what Carsten was proposing. But its not obvious to
me how much common mechanism can be pulled out, since its a pretty
deeply architecture-specific operation.
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:[~2007-06-29 14:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-26 11:08 RFC: multiple address spaces for one process Peter Chubb
2007-06-26 11:08 ` Peter Chubb
2007-06-29 14:32 ` Jeremy Fitzhardinge [this message]
2007-06-29 14:32 ` Jeremy Fitzhardinge
2007-06-30 4:19 ` Carsten Otte
2007-06-30 4:19 ` Carsten Otte
2007-06-30 9:59 ` Peter Chubb
2007-06-30 9:59 ` Peter Chubb
2007-06-30 16:30 ` Jeremy Fitzhardinge
2007-06-30 16:30 ` Jeremy Fitzhardinge
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=468517E1.4050803@goop.org \
--to=jeremy@goop.org \
--cc=cotte@de.ibm.com \
--cc=linux-mm@kvack.org \
--cc=peterc@gelato.unsw.edu.au \
--cc=virtualization@lists.linux-foundation.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.