netdev - Re: [GIT PULL] AlacrityVM guest drivers for 2.6.33

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B2FAF53.2080601@gmail.com>
Date:	Mon, 21 Dec 2009 12:24:35 -0500
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Avi Kivity <avi@...hat.com>
CC:	Anthony Liguori <anthony@...emonkey.ws>,
	Ingo Molnar <mingo@...e.hu>, kvm@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	torvalds@...ux-foundation.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	netdev@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>
Subject: Re: [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

Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)