Hi,
At 12:37 +0100 on 21 Apr (1240317466), priya sehgal wrote:
> We have a course project, in which we have to improve the performance
> of live migration for HVM guests. It seems that to support live
> migration, all the page table entries in the shadow page table are
> marked as write protected, so as to know which pages are dirtied and
> to be sent to the other machine. Since, there will be many page faults
> leading to performance degradation, we want to reduce these page
> faults. In our course project, we are supposed to form groups of pages
> and if any page in the group hits the page fault (due to
> write-protection), we mark all the pages in the group as RW. This way
> we can reduce the page faults.
I see. Yes, in the shadow pagetables that should be easy enough; the
shadow_set_l1e() function is where the read-only mapping will be
replaced by a read-write one, which should be a hint that you might want
to reconsider its neighbours.
> This is based on some hueristic that if a page is written, its
> immediate neighbors will also be written.
I'd be interested to hear how it trades off against increaded bandwicth
use.
Cheers,
Tim.
> My concern was that since we will be touching the same shadow page
> table and marking its PTEs as RO or RW during different epochs we
> should not break something existing.
>
> Priya.I
> --- On Tue, 4/21/09, Tim Deegan <Tim.Deegan@xxxxxxxxxx> wrote:
>
> > From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> > Subject: Re: [Xen-devel] Shadow Page Tables in Xen
> > To: "priya sehgal" <priyagps@xxxxxxxxxxx>
> > Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
> > Date: Tuesday, April 21, 2009, 2:07 PM
> > Hi,
> >
> > At 20:34 +0100 on 20 Apr (1240259658), priya sehgal wrote:
> > > I was going through the memory management in Xen and
> > little confused
> > > about shadow page tables for HVM guest and how they
> > work.
> >
> > Why are you interested? Do you have a project in
> > mind?
> >
> > > Few of my questions are :
> > > 1. A shadow page table, is a copy of the guest page
> > table, with actual machine frame numbers (MFN), as against
> > the physical page number(PFN) in case of guests.
> > > Do the shadow page tables write protect each of the
> > PTE it contains, or only the pages containing the "guest
> > page table" are write protected (to check if the guest has
> > modified any entry)?
> >
> > They write-protect all pagetables and some other things but
> > not all of
> > memory; that wouldn't be very useful.
> >
> > > 2. I know that live migration is supported on xen, but
> > not sure if it works for HVM guests. In this case also, xen
> > will need to keep a shadow page table, which should detect
> > which pages have been modified since the last time the pages
> > were migrated. For this, shadow page table should mark all
> > the PTEs as write protected. Does xen implement live
> > migration of HVM guests in this way ?
> > > If yes, then is this shadow table same as the one used
> > in (1), or there are multiple copies of the shadow tables
> > for different purposes?
> >
> > There's only one set of shadows, since the MMU can only use
> > one at a
> > time.
> >
> > Cheers,
> >
> > Tim.
> >
> > > Thanks.
> > > Priya
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/xen-devel
> >
> > --
> > Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> > Principal Software Engineer, Citrix Systems (R&D) Ltd.
> > [Company #02300071, SL9 0DZ, UK.]
> >
>
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home