On Tue, Feb 14, 2017 at 11:17:41AM -0800, Benjamin Serebrin wrote: > On Wed, Feb 8, 2017 at 11:37 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > IIRC irqbalance will bail out and avoid touching affinity > > if you set affinity from driver. Breaking that's not nice. > > Pls correct me if I'm wrong. > > > I believe you're right that irqbalance will leave the affinity alone. > > Irqbalance has had changes that may or may not be in the versions bundled with > various guests, and I don't have a definitive cross-correlation of irqbalance > version to guest version. But in the existing code, the driver does > set affinity for #VCPUs==#queues, so that's been happening anyway. Right but only for the case where we are very sure we are doing the right thing, so we don't need any help from irqbalance. > The (original) intention of this patch was to extend the existing behavior > to the case where we limit queue counts, to avoid the surprising discontinuity > when #VCPU != #queues. > > It's not obvious that it's wrong to cause irqbalance to leave these > queues alone: Generally you want the interrupt to come to the core that > caused the work, to have cache locality and avoid lock contention. > Doing fancier things is outside the scope of this patch. Doing fancier things like trying to balance the load would be in scope for irqbalance so I think you need to find a way to supply default affinity without disabling irqbalance. > > Doesn't look like this will handle the case of num cpus < num queues well. > > I believe it's correct. The first #VCPUs queues will have one bit set in their > xps mask, and the remaining queues have no bits set. That means each VCPU uses > its own assigned TX queue (and the TX interrupt comes back to that VCPU). > > Thanks again for the review! > Ben -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
