Keir: This is patch to move PIC mask/EOI access to HV for performance and we saw about 5% performance increasement with this patch. Signed-off-by: Eddie Dong <eddie.dong@intel.com> Thanks, eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Sep 2005, at 10:33, Dong, Eddie wrote:> Keir: > This is patch to move PIC mask/EOI access to HV for performance > and we saw about 5% performance increasement with this patch.I''m not sure about this. I don''t much like splitting the implementation of a device across both Xen and qemu -- I''d rather implement entirely within one or the other. Our eventual aim should be to move all non-Xen device models into the context of the vmx domain (running as a paravirt ''mini domain'' in rings 1 to 3 of the root vmcs). This might reduce latency enough for most devices to avoid distasteful ''split'' device-model implementations. In the case of local APICs, I/O APICs and the legacy PIC I can accept that, even in the above model there will probably be a measurable performance improvement to implementing these devices within Xen. But I think this should be done by moving their complete implementation into Xen and defining a clean interface to device models running in domain0 and/or rings 1-3. In the case of the PIC, this could be done by having a virtualised ''interrupt wire'' for each device (e.g., represent an ''interrupt edge'' by a special call into Xen that runs the PIC device model). The other argument for putting the PIC and IO-APIC in Xen is that the PIT is already there, and having it call out into a non-Xen device model to send interrupts is rather gross. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser wrote:> On 22 Sep 2005, at 10:33, Dong, Eddie wrote: > >> Keir: >> This is patch to move PIC mask/EOI access to HV for performance >> and we saw about 5% performance increasement with this patch. > > I''m not sure about this. I don''t much like splitting the > implementation of a device across both Xen and qemu -- I''d rather > implement entirely within one or the other. Our eventual aim should > be to move all non-Xen device models into the context of the vmx > domain (running as a paravirt ''mini domain'' in rings 1 to 3 of the > root vmcs). This might reduce latency enough for most devices to > avoid distasteful ''split'' device-model implementations.Yes agree, the eventual goal should move device model to mini-domain.> > In the case of local APICs, I/O APICs and the legacy PIC I can accept > that, even in the above model there will probably be a measurable > performance improvement to implementing these devices within Xen. ButFor PIC case, cpusoak saw 5% performance increasement on REL4U1.> I think this should be done by moving their complete implementation > into Xen and defining a clean interface to device models running in > domain0 and/or rings 1-3. In the case of the PIC, this could be done > by having a virtualised ''interrupt wire'' for each device (e.g., > represent an ''interrupt edge'' by a special call into Xen that runs > the PIC device model).Yes, moving entire PIC into HV is another good approach.> > The other argument for putting the PIC and IO-APIC in Xen is that the > PIT is already there, and having it call out into a non-Xen device > model to send interrupts is rather gross. >Understand, so you prefer to see entire PIC in HV at least for Xen3.0. Right? Or should we use this patch for now and do various performance tunning in parallel?> -- KeirThanks,eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 22 Sep 2005, at 13:24, Dong, Eddie wrote:> Understand, so you prefer to see entire PIC in HV at least for Xen3.0. > Right? > Or should we use this patch for now and do various performance tunning > in > parallel?Right now I don''t much care about 5% performance improvement in vmx, since noone is using it as the hardware isn''t available. I''m therefore happy to wait for a more desirable patch than accept this a stopgap measure. If you provide a patch that cleanly moves PIC (and IO-APIC, when it''s ready) code into Xen, I will accept it in a heartbeat. I reckon that ought to clean up the interrupt-related parts of the PIT code too (and the local APIC code, when it''s ready). I really want to see vmx cleanups, bug fixes, and patches that move us closer to the ideal architecture that we have in mind. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel