Comment 38 for bug 1833322

Hey Henry, thanks for chiming in and I agree in general that tech moved on.
Myself and others said similar before, thanks for adding more details and voices - that is what such a discussion is about.

> they just don't go ping-ponging around between

In particular on this aspect, so much has happened with fast devices often not only "not being bottle-necked" but even I/O interaction routing smartly, I mentioned for example rps/xps on here before.

Still, there are even today a few workloads - usually high utilization large scale loads that benefit.
Thanks @John for carrying a few of them forward to this bug!

But the more I read, the more people chime in, ... the more one pattern seems to crystallize (for me).
I'll try to summarize my gut-feeling so far... (which is my opinion so far, not more):
"""
While it seems a few high intensity workloads still can benefit, those are of the kind that are usually hand-optimized and could easily pull-in irqbalance if needed.

On the other hand the majority of workloads do not care either way - at least not in an easily provable way.

And furthermore most of the need to have it in the past has been replaced by newer I/O architectures.

Finally there also have been some cases that suffered from irqbalance being enabled. Those cases in particular seem to be those of end-users, often Desktop end users that might not always tune their system intensely.

For consistency between Server and Desktop I'd prefer to change it in both in the same way, while the cases still benefiting all where server'ish there hasn't been a case that would need it by default.

Overall that makes me think that we could indeed change it to not be enabled by default anymore in the upcoming Noble release.
"""

I know that Steve (@vorlon) wanted to comment on this as well, maybe we have sufficient statements, opinions and at least a bit of data so far to have a decision for Noble before Feature freeze?