> > > > >> Plenty of IO workloads build up utilization perfectly fine. > > > > These ones have no problems, no? They should migrate to big core and the > > completion will follow them when they move. > > So if I understood Manish correctly the only reason they want the completion > to run on a bigger CPU than the submission is because the submission is already > saturating the CPU, therefore utilization of submission is no issue whatsoever. > They don't want to run (submission) on big though because of power > considerations. Is this what rq_affinity=1 means? This use case is rq_affinity=0. IOW, custom affinity management. > > > > >> I wouldn't consider the setup: requester little perf, irq+completion big perf > >> invalid necessarily, it does decrease IO latency for the application. > > > > I didn't say invalid. But it is not something we can guess automatically when > > irq_affinity=1. We don't have enough info to judge. The only info we have the > > requester that originated the request is running at different perf level > > (whther higher or lower), so we follow it. > > > Anyway, Manish's problem should be solved by rq_affinity=0 in that case (with > irq affinities set to big CPU then the completion will be run on the irq CPU) > and "rq_affinity=1 <=> equal capacity CPU" is the correct interpretation, is that > more or less agreed upon now? > I think this is the sensible route. The sensible extensions I foresee is teaching how to discern different cases rather than add a hacky flag to confuse what rq_affinity=1 means.
