Re: [patch 00/13] RFC: split the global mutex

[Avi Kivity <avi@qumranet.com>]

Marcelo Tosatti wrote:
> On Sun, Apr 20, 2008 at 02:16:52PM +0300, Avi Kivity wrote:
>   
>>> The iperf numbers are pretty good. Performance of UP guests increase 
>>> slightly but SMP
>>> is quite significant.
>>>       
>> I expect you're seeing contention induced by memcpy()s and inefficient 
>> emulation.  With the dma api, I expect the benefit will drop.
>>     
>
> You still have to memcpy() with the dma api. Even with vringfd the
> kernel->user copy has to be performed under the global mutex protection,
> difference being that several packets can be copied per-syscall instead
> of only one.
>
>   

Block does the copy outside the mutex protection, so net can be adapted 
to do the same.  It does mean we will need to block all I/O temporarily 
during memory hotplug.

>> For pure cpu emulation, there is a ton of work to be done: protecting
>> the translator as well as making the translated code smp safe.
>>     
>
> I now believe there is a lot of work (which was not clear before).
> Not particularly interested in getting real emulation to be
> multithreaded.
>
> Anyways, the lack of multithreading in qemu emulation should not be a
> blocker for these patches to get in, since these are infrastructural
> changes.
>
>   

Getting this into qemu upstream is essential as this is far more 
intrusive than anything else we've done.  But again, I believe there are 
many other fruit hanging from lower branches.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone