netdev - Re: [PATCH] vhost: Make it more scalable by creating a vhost thread per device.

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: <4BBB822D.7050400@redhat.com>
Date:	Tue, 06 Apr 2010 21:49:17 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Sridhar Samudrala <sri@...ibm.com>
CC:	"Michael S. Tsirkin" <mst@...hat.com>,
	Tom Lendacky <toml@...ibm.com>,
	netdev <netdev@...r.kernel.org>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: Re: [PATCH] vhost: Make it more scalable by creating a vhost	thread
 per device.

On 04/05/2010 08:35 PM, Sridhar Samudrala wrote:
> On Sun, 2010-04-04 at 14:14 +0300, Michael S. Tsirkin wrote:
>    
>> On Fri, Apr 02, 2010 at 10:31:20AM -0700, Sridhar Samudrala wrote:
>>      
>>> Make vhost scalable by creating a separate vhost thread per vhost
>>> device. This provides better scaling across multiple guests and with
>>> multiple interfaces in a guest.
>>>        
>> Thanks for looking into this. An alternative approach is
>> to simply replace create_singlethread_workqueue with
>> create_workqueue which would get us a thread per host CPU.
>>
>> It seems that in theory this should be the optimal approach
>> wrt CPU locality, however, in practice a single thread
>> seems to get better numbers. I have a TODO to investigate this.
>> Could you try looking into this?
>>      
> Yes. I tried using create_workqueue(), but the results were not good
> atleast when the number of guest interfaces is less than the number
> of CPUs. I didn't try more than 8 guests.
> Creating a separate thread per guest interface seems to be more
> scalable based on the testing i have done so far.
>    

Thread per guest is also easier to account.  I'm worried about guests 
impacting other guests' performance outside scheduler control by 
extensive use of vhost.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

--
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