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: <4B323353.8000607@codemonkey.ws>
Date:	Wed, 23 Dec 2009 09:12:19 -0600
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Chris Wright <chrisw@...s-sol.org>
CC:	Andi Kleen <andi@...stfloor.org>,
	Gregory Haskins <gregory.haskins@...il.com>,
	Avi Kivity <avi@...hat.com>, 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/22/2009 06:02 PM, Chris Wright wrote:
> * Anthony Liguori (anthony@...emonkey.ws) wrote:
>> The
>> virtio-net setup probably made extensive use of pinning and other tricks
>> to make things faster than a normal user would see them.  It ends up
>> creating a perfect combination of batching which is pretty much just
>> cooking the mitigation schemes to do extremely well for one benchmark.
>
> Just pinning, the rest is stock virtio features like mergeable rx buffers,
> GRO, GSO (tx mitigation is actually disabled).

Technically, tx mitigation isn't disabled.  The heuristic is changed 
such that instead of relying on a fixed timer, tx notification is 
disabled until you can switch to another thread and process packets.

The effect is that depending on time slice length and system load, you 
adaptively enable tx mitigation.  It's heavily dependent on the 
particulars of the system and the overall load.

For instance, this mitigation scheme looks great at high throughputs but 
looks very bad at mid-to-low throughputs compared to timer based 
mitigation (at least, when comparing CPU cost).

Regards,

Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html