On 12/21/09 12:05 PM, Avi Kivity wrote: > On 12/21/2009 06:56 PM, Gregory Haskins wrote: >>> I'm working on disappearing EOI exits on older hardware as well. Same >>> idea as the old TPR patching, without most of the magic. >>> >>> >> While I applaud any engineering effort that results in more optimal >> execution, if you are talking about what we have discussed in the past >> its not quite in the same league as my proposal. >> > > I don't doubt this for a minute. > >> You are talking about the ability to optimize the final EOI if there are >> no pending interrupts remaining, right? The problem with this approach >> is it addresses the wrong side of the curve: That is, it optimizes the >> code as its about to go io-idle. You still have to take an extra exit >> for each injection during the heat of battle, which is when you actually >> need it most. >> > > No, it's completely orthogonal. An interrupt is injected, the handler > disables further interrupts and EOIs, then schedules the rest of the > handling code. So long as there as packets in the ring interrupts won't > be enabled and hence there won't be any reinjections. I meant inter-vector "next-interrupt" injects. For lack of a better term, I called it reinject, but I realize in retrospect that this is ambiguous. > > Different interrupt sources still need different interrupts, but as all > of your tests have been single-interface, this can't be the reason for > your performance. > Actually I have tested both single and multi-homed setups, but it doesn't matter. Even a single device can benefit, as even single devices may have multiple vector sources that are highly probably to generate coincident events. For instance, consider that even a basic ethernet may have separate vectors for "rx" and "tx-complete". A simple ping is likely to generate both vectors at approximately the same time, given how the host side resources often work. Trying to condense multiple vectors into one means its up to the driver to implement any type of prioritization on its own (or worse, it just suffers from PI). Likewise, implementing them as unique vectors means you are likely to have coincident events for certain workloads. What alacrityvm tries to do is recognize these points and optimize for both cases. It means we still retain framework-managed prioritized callbacks, yet optimize away extraneous IO for coincident signals. IOW: best of both worlds. Kind Regards, -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
