[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.