[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] PML (Page Modification Logging) design for Xen



> From: Tim Deegan [mailto:tim@xxxxxxx]
> Sent: Thursday, February 12, 2015 8:42 PM
> 
> At 07:08 +0000 on 12 Feb (1423721283), Tian, Kevin wrote:
> > for general log dirty, ept_invalidate_emt is required because there is
> > access permission change (dirtied page becomes rw after 1st fault,
> > so need to change them back to ro again for the new dirty tracking
> > round). But for PML, there's no permission change at all (always rw),
> > so such behavior should be noted by general logdirty layer for better
> > optimization.
> 
> AIUI the reason for calling ept_invalidate_emt() is to avoid having to
> update a large number of EPTEs at once.  If you still need to update a
> large number of EPTEs (to clear the Dirty bits), that has to me
> preemptable, or else use ept_invalidate_emt().
> 
> Or have I misunderstood?
> 

preemptable is fine and we can judge whether dirty set is large or not. 
My feeling is that replace simple D-bit cleanup with ept misconfig exit
is not optimal. Jan explained not strictly one misconfig exit for every D 
bit since whole L1 will be handled in a batch, but we need have some 
understanding of actual impact based on various workload patterns.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.