[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] Regarding page table management changes from Xen v1to Xen v2 (and v3)
> Although, same results can be obtained by doing the v1.2 way, > i.e. making one hypercall requesting these 1024 changes, no? No, not easily -- the batched interface has problems with SMP guests, as the updates may be expected to be individually atomic. Ian > On Wed, Apr 26, 2006 at 05:18:28PM +0100, Keir Fraser wrote: > > > > On 26 Apr 2006, at 16:35, Himanshu Raj wrote: > > > > >I am trying to understand the rationale behind this change. In > > >previous case, there would be no page faults due to page table > > >updates and only one hypercall. > > >In the second case, there would be atleast 2 page faults due to PT > > >management activity, but no hypercalls. Besides, mapping and > > >remapping with different permissions imply removing this > entry from > > >TLB (which is hopefully being done with invlpg). > > >Benefit of latter approach only seems to be the removal of xen > > >specific linux code. Why was the approach changed? Could someone > > >please shed some light on this? > > > > It's useful for batched updates (e.g., fork()) where the 2 > faults are > > amortised across up to 1024 pte changes. > > > > -- Keir > > -- > -------------------------------------------------------------- > ----------- > Himanshu Raj > PhD Student, GaTech (www.cc.gatech.edu/~rhim) I prefer to > receive attachments in an open, non-proprietary format. > -------------------------------------------------------------- > ----------- > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxx > http://lists.xensource.com/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |