lkml.org 
[lkml]   [2009]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] AlacrityVM guest drivers for 2.6.33
    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



    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2009-12-21 18:27    [W:6.236 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site