Re: [patch V6 00/16] Improve /proc/interrupts further

[Shrikanth Hegde <sshegde@linux.ibm.com>]

On 5/21/26 1:23 PM, Thomas Gleixner wrote:
>>> Shrikanth!
> 
> On Thu, May 21 2026 at 10:04, Shrikanth Hegde wrote:
>> On 5/20/26 8:57 PM, Thomas Gleixner wrote:
>>> Can you redirect it to /dev/null instead to take the file operations out
>>> of the picture?
>>
>> Yes. Did "perf stat -r 1000 cat /proc/interrupts > /dev/null".
>> It shows better improvement with the series compared to file write.
> 
> Unsurprisingly :)
> 
>>>>           0.000490211 +- 0.000000992 seconds time elapsed  ( +-  0.20% )   <<< 3-4% improvements.
>>>
>>> Again IPC drops ....
>>
>> Yes. IPC dropping is consistent. I see the same trend in (PATCH 1/16) in the series.
>> Copying that snippet below.
>>
>> Before:
>>    8,932,242      instructions      #    1.66  insn per cycle  ( +-  0.34% )
>> After:
>>    7,020,982      instructions      #    1.30  insn per cycle  ( +-  0.52% )
>>
>> So it might be common pattern across archs. Maybe perf stat subsystem is slow
>> enough it doesn't shows the aboslute benefit.
> 
> The problem is that the overhead of starting and tearing down 'cat' is
> accounted as well. That's constant, obviously.
> 
> But for the use cases like irqbalanced or similar things, there is no
> startup/teardown cost involved. The process is up and running and they
> care about the actual read performance.
> 

true.

> It's clearly to observe by comparing the perf data with the read loop
> timing data:
> 
>            Base line		v6
> Perf	  3072.21 us		1564.40 us
> Loop	  1310.36 us		 209.90 us
> 
> It doesn't add up completely, but the trend is there. And you can trick
> perf to reveal the startup/teardown overhead it by comparing:
> 
>    perf stat -r 1000 head -q -c -0 /proc/interrupts >/dev/null
>    perf stat -r 1000 head -q -c 0 /proc/interrupts >/dev/null
> 

Tried it, but doesn't affect much.

>> In addition, I ran "perf stat -a -r 1000 cat /proc/interrupts > /dev/null"
>> It is now 10x slower. IPC is same with series And improvement vanishes.
>> So heavier the infra testing it, gains are getting minimal i guess.
> 
> As often :)
> 
>> But i don't see any regression.
>>
>> As you said in the cover-letter, the micro loops you ran maybe the best way to evaluate it.
>> If you have the code in shareable form, I can give it a try.
> 
> See below. I thought I would come around some day to actually use perf
> directly in the test program, but that never happened due to
> -ENOTIME.
> 
> Thanks,
> 
>          tglx
> ---
> #include <fcntl.h>
> #include <math.h>
> #include <stdio.h>
> #include <time.h>
> #include <unistd.h>
> 
> static char buf[1024*1024];
> 
> #define NSECS_PER_SEC	(1000L * 1000L * 1000L)
> 
> #define LOOPS	1000
> 
> static float td[LOOPS];
> 
> int main(int argc, char *argv[])
> {
> 	int fd = open("/proc/interrupts", O_RDONLY);
> 	long tsum = 0, rs = 0;
> 
> 	for (int i = 0; i < LOOPS; i++) {
> 		long r;
> 
> 		do {
> 			r = read(fd, buf, sizeof(buf));
> 		} while (r);
> 		lseek(fd, 0, 0);
> 	}
> 
> 	for (int i = 0; i < LOOPS; i++) {
> 		struct timespec t0, t1;
> 		unsigned long delta;
> 		long r;
> 
> 		clock_gettime(CLOCK_MONOTONIC, &t0);
> 		do {
> 			r = read(fd, buf, sizeof(buf));
> 			rs += r;
> 		} while (r);
> 		clock_gettime(CLOCK_MONOTONIC, &t1);
> 
> 		delta = t1.tv_nsec + t1.tv_sec * NSECS_PER_SEC;
> 		delta -= t0.tv_nsec + t0.tv_sec * NSECS_PER_SEC;
> 		tsum += delta;
> 		td[i] = delta * 1.0;
> 
> 		lseek(fd, 0, 0);
> 	}
> 
> 	float mean = tsum / LOOPS;
> 	float calc = 0;
> 
> 	for (int i = 0; i < LOOPS; i++) {
> 		float tmp = td[i] - mean;
> 
> 		calc += tmp * tmp;
> 	}
> 
> 	calc /= LOOPS;
> 
> 	float std = sqrt(calc * 1.0);
> 
> 	printf("%lu %lu %5.3f\n", tsum / LOOPS, rs / LOOPS, (std / mean) * 100.0);
> 	return 0;
> }

This shows real benefits indeed.

base		  v6		v6+ppc_hack
101us		65us                  57us

So doing a proper powerpc fix indeed would make sense.
I think it is going to be similar. Let me go and read your
series again.


For the genirq bits of the series, consider the tag if applicable

Tested-by: Shrikanth Hegde <sshegde@linux.ibm.com>