[Xen-devel] Re: Question about x86/mm/gup.c's use of disabled interrupts

[Avi Kivity <avi@xxxxxxxxxx>]

Jeremy Fitzhardinge wrote:
> Avi Kivity wrote:
> > > And the hypercall could result in no Xen-level IPIs at all, so it 
> > > could be very quick by comparison to an IPI-based Linux 
> > > implementation, in which case the flag polling would be particularly 
> > > harsh.
> > Maybe we could bring these optimizations into Linux as well.  The 
> > only thing Xen knows that Linux doesn't is if a vcpu is not 
> > scheduled; all other information is shared.
> I don't think there's a guarantee that just because a vcpu isn't 
> running now, it won't need a tlb flush.  If a pcpu does runs vcpu 1 -> 
> idle -> vcpu 1, then there's no need for it to do a tlb flush, but the 
> hypercall can make force a flush when it reschedules vcpu 1 (if the 
> tlb hasn't already been flushed by some other means).
That's what I assumed you meant.  Also, if a vcpu has a different cr3 
loaded, the flush can be elided.  Looks like Linux does this 
(s/vcpu/process/).
> (I'm not sure to what extent Xen implements this now, but I wouldn't 
> want to over-constrain it.)
Well, kvm does this.


> > The nice thing about local_irq_disable() is that it scales so well.
> Right.  But it effectively puts the burden on the tlb-flusher to check 
> the state (implicitly, by trying to send an interrupt).  Putting an 
> explicit poll in gets the same effect, but its pure overhead just to 
> deal with the gup race.
I guess it hopes the flushes are much rarer.  Certainly for threaded 
databases doing O_DIRECT stuff, I'd expect lots of gupfs and no tlb flushes.

--
error compiling committee.c: too many arguments to function


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel