Re: [PATCH V4 0/3] xen-netback: switch to NAPI + kthread 1:1 model

[annie li <annie.li@oracle.com>]

On 2013-8-22 23:12, Wei Liu wrote:
> On Tue, Aug 06, 2013 at 03:17:46PM +0100, Andrew Bennieston wrote:
>> On 06/08/13 14:29, David Vrabel wrote:
>>> On 06/08/13 14:16, Pasi Kärkkäinen wrote:
>>>> On Tue, Aug 06, 2013 at 10:06:00AM +0100, Wei Liu wrote:
>>>>> IRQs are distributed to 4 cores by hand in the new model, while in the
>>>>> old model vifs are automatically distributed to 4 kthreads.
>>>>>
>>>> Hmm.. so with these patches applied is is *required* to do manual configuration in dom0 to get good performance?
>>> This should be irqbalanced's job.  The existing version doesn't do a
>>> good enough job yet though.  Andrew Bennieston may have more details.
>>>
>>> David
>>>
>> irqbalance 1.0.6 [1] includes a patch [2] from Wei Liu [3] that adds
>> support for balancing `xen-dyn-event' interrupts. When I have compiled
>> this version and run it under Xen(Server) I noticed that the
>> interrupts are indeed moving between cores, but not necessarily in
>> what I would call an obvious or optimal way (e.g. several VIF
>> interrupts are being grouped onto a single dom0 VCPU at times). I plan
>> on investigating this further when time permits.
>>
>> I also noticed that, from time to time, the irqbalance process
>> disappears. I tracked this down to a segfault that occurs when a VM
>> shuts down and an IRQ disappears during one of irqbalance's periodic
>> rescans. I'm hoping to be able to narrow this down sufficiently to
>> identify the cause and ideally fix it, but I don't have a lot of time
>> to work on this at the moment.
>>
>> As for the impact on Wei's patches, without irqbalance it would be
>> trivial to automatically assign (via a script, on VM start) the
>> interrupts for a particular VIF to a particular dom0 vCPU in a
>> round-robin fashion, just as VIFs were previously assigned to netback
>> kthreads. This would result in broadly the same performance as before,
>> while an improved irqbalanced should give better performance and
>> fairness when two different VIFs would otherwise be competing for the
>> same resources.
>>
> So can I conclude that this model doesn't incur severe performance
> regression, on the other hand it has its advantage on fairness so it's
> worth upstreaming?
I agree.
 From Andrew's result, I do not see any bad affect about this model, and 
well worked irqbalance may give us much better performance too.
And this can also simplify persistent map patch(it is kind of stopped, 
but my recent test shows some good results)
>
> If so I will post another series shortly with all comments addressed.
Please go ahead.

Thanks
Annie