On Wed, Feb 15, 2017 at 9:42 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > > > For pure network load, assigning each txqueue IRQ exclusively > > to one of the cores that generates traffic on that queue is the > > optimal layout in terms of load spreading. Irqbalance does > > not have the XPS information to make this optimal decision. > > Try to add hints for it? > > > > Overall system load affects this calculation both in the case of 1:1 > > mapping uneven queue distribution. In both cases, irqbalance > > is hopefully smart enough to migrate other non-pinned IRQs to > > cpus with lower overall load. > > Not if everyone starts inserting hacks like this one in code. It seems to me that the default behavior is equally "random" - why would we want XPS striped across the cores the way it's done today? What we're trying to do here is avoid the surprise cliff that guests will hit when queue count is limited to less than VCPU count. That will happen because we limit queue pair count to 32. I'll happily push further complexity to user mode. If this won't fly, we can leave all of this behavior in user code. Michael, would you prefer that I abandon this patch? > That's another problem with this patch. If you care about hyperthreads > you want an API to probe for that. It's something of a happy accident that hyperthreads line up that way. Keeping the topology knowledge out of the patch and into user space seems cleaner, would you agree? Thanks! 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
