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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.15 at 03:28, <kevin.tian@xxxxxxxxx> wrote:
>>  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.

What alternatives do you see when dealing with a global run over
all entries?

Jan


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