On Mon, May 17, 2021 at 8:04 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > > On Mon, May 17 2021 at 18:44, Nitesh Lal wrote: > > On Mon, May 17, 2021 at 4:48 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > >> The hint was added so that userspace has a better understanding where it > >> should place the interrupt. So if irqbalanced ignores it anyway, then > >> what's the point of the hint? IOW, why is it still used drivers? > >> > > Took a quick look at the irqbalance repo and saw the following commit: > > > > dcc411e7bf remove affinity_hint infrastructure > > > > The commit message mentions that "PJ is redesiging how affinity hinting > > works in the kernel, the future model will just tell us to ignore an IRQ, > > and the kernel will handle placement for us. As such we can remove the > > affinity_hint recognition entirely". > > No idea who PJ is. I really love useful commit messages. Maybe Neil can > shed some light on that. > > > This does indicate that apparently, irqbalance moved away from the usage of > > affinity_hint. However, the next question is what was this future > > model? > > I might have missed something in the last 5 years, but that's the first > time I hear about someone trying to cleanup that thing. > > > I don't know but I can surely look into it if that helps or maybe someone > > here already knows about it? > > I CC'ed Neil :) Thanks, I have added PJ Waskiewicz as well who I think was referred in that commit message as PJ. > > >> Now there is another aspect to that. What happens if irqbalanced does > >> not run at all and a driver relies on the side effect of the hint > >> setting the initial affinity. Bah... > >> > > > > Right, but if they only rely on this API so that the IRQs are spread across > > all the CPUs then that issue is already resolved and these other drivers > > should not regress because of changing this behavior. Isn't it? > > Is that true for all architectures? Unfortunately, I don't know and that's probably why we have to be careful. -- Nitesh
