linux-kernel - 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]

Date:	Mon, 21 Dec 2009 19:05:06 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Gregory Haskins <gregory.haskins@...il.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/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.

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.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/