Re: [PATCH v2 00/14] Introducing TIF_NOTIFY_IPI flag
K Prateek Nayak <[email protected]>
| Newsgroups | gmane.linux.ports.alpha,gmane.linux.kernel,gmane.linux.ports.arm.kernel,gmane.linux.ports.parisc,gmane.linux.ports.ppc64.devel,gmane.linux.ports.sh.devel,gmane.linux.ports.sparc,gmane.linux.power-management.general |
|---|---|
| Message-ID | <[email protected]> |
Hello Russell, On 6/15/2024 7:56 PM, Russell King (Oracle) wrote: > On Thu, Jun 13, 2024 at 06:15:59PM +0000, K Prateek Nayak wrote: >> o Dropping the ARM results since I never got my hands on the ARM64 >> system I used in my last testing. If I do manage to get my hands on it >> again, I'll rerun the experiments and share the results on the thread. >> To test the case where TIF_NOTIFY_IPI is not enabled for a particular >> architecture, I applied the series only until Patch 3 and tested the >> same on my x86 machine with a WARN_ON_ONCE() in do_idle() to check if >> tif_notify_ipi() ever return true and then repeated the same with >> Patch 4 applied. > > Confused. ARM (32-bit) or ARM64? You patch 32-bit ARM, but you don't > touch 64-bit Arm. "ARM" on its own in the context above to me suggests > 32-bit, since you refer to ARM64 later. > In my first RFC posting, I had shared the results for ipistorm on an ARM64 server [1]. Vincent and Linus Walleij brought to my attention that ARM32 and ARM64 do not share the thread info flags and I probably saw a one-off behavior during my testing. Since then, it has been slightly challenging to get my hands on that machine again in a stable condition to see if there was any scenario that I might have missed but I tried a bunch of things on my x86 machine to confirm that an arch that does not define the TIF_NOTIFY_IPI would not hit these changes. Rest assured, Patch 5 is for ARM32 machines that currently define TIF_POLLING_NRFLAG [1] https://lore.kernel.org/lkml/[email protected]/ -- Thanks and Regards, Prateek