[RFC PATCH 00/14] Introducing TIF_NOTIFY_IPI flag

[K Prateek Nayak]

Hello Linus,

Thank you for taking a look at the patch.

On 3/6/2024 3:14 PM, Linus Walleij wrote:
> Hi K Prateek,
> 
> I trimmed down the recipient list so we don't bounce.
> 
> On Tue, Feb 20, 2024 at 6:15 PM K Prateek Nayak <kprateek.nayak at amd.com> wrote:
> 
>> Same experiment was repeated on an dual socket ARM server (2 x 64C)
>> which too saw a significant improvement in the ipistorm performance:
>>
>>   ==================================================================
>>   Test          : ipistorm (modified)
>>   Units         : Normalized runtime
>>   Interpretation: Lower is better
>>   Statistic     : AMean
>>   ==================================================================
>>   kernel:                               time [pct imp]
>>   tip:sched/core                        1.00 [0.00]
>>   tip:sched/core + TIF_NOTIFY_IPI       0.41 [59.29]
> 
> Is that a 64bit ARM64 system or really an ARM 32-bit 64-core system?
> 
> I'm confused because:
> 
>> K Prateek Nayak (10):
>>   arm/thread_info: Introduce TIF_NOTIFY_IPI flag
> 
> There is no arm64 patch in the patch series.

When I started out, assumed both arm32 and arm64 shared the same
thread_info file. I basically ran:

	$ grep -r "TIF_POLLING_NRFLAG" arch/arm*
	arch/arm/include/asm/thread_info.h: *  TIF_POLLING_NRFLAG       - true if poll_idle() is polling TIF_NEED_RESCHED

and reached here but now I see "arch/arm64/include/asm/thread_info.h".
The machine I tested on was "aarch64" and was listed "Neoverse-N1" as
the "Model name" when running lscpu. This series changes some behavior
around IPI delivery to an idle thread but without "TIF_POLLING_NRFLAG"
defined, the behavior should remain same. I have limited access to the
server I tested on. Let me see if I can get some cycles to test this
once again.

> 
> I can perhaps test the patches on an ARM32 system but all I have is dualcore
> I think.
> 
> Yours,
> Linus Walleij

--
Thanks and Regards,
Prateek