On Thu, May 20, 2021 at 5:57 PM Nitesh Lal <nilal@xxxxxxxxxx> wrote: > > On Mon, May 17, 2021 at 8:23 PM Nitesh Lal <nilal@xxxxxxxxxx> wrote: > > > > 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. > > I think here to ensure that we are not breaking any of the drivers we have > to first analyze all the existing drivers and understand how they are using > this API. > AFAIK there are three possible scenarios: > > - A driver use this API to spread the IRQs > + For this case we should be safe considering the spreading is naturally > done from the IRQ subsystem itself. Forgot to mention another thing in the above case is to determine whether it is true for all architectures or not as Thomas mentioned. > > - A driver use this API to actually set the hint > + These drivers should have no functional impact because of this revert > > - Driver use this API to force a certain affinity mask > + In this case we have to replace the API with the irq_force_affinity() > > I can start looking into the individual drivers, however, testing them will > be a challenge. > > Any thoughts? > > -- > Thanks > Nitesh -- Thanks Nitesh
