From: Thomas Gleixner <tglx@kernel.org>
To: Shrikanth Hegde <sshegde@linux.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, Michael Kelley <mhklinux@outlook.com>,
Dmitry Ilvokhin <d@ilvokhin.com>, Radu Rendec <radu@rendec.net>,
Jan Kiszka <jan.kiszka@siemens.com>,
Kieran Bingham <kbingham@kernel.org>,
Florian Fainelli <florian.fainelli@broadcom.com>,
Marc Zyngier <maz@kernel.org>
Subject: Re: [patch V6 00/16] Improve /proc/interrupts further
Date: Thu, 21 May 2026 09:53:00 +0200 [thread overview]
Message-ID: <87jysxw65f.ffs@tglx> (raw)
In-Reply-To: <0ef61565-dc6c-4281-ad85-ddfff87078a7@linux.ibm.com>
>> 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.
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
> 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;
}
next prev parent reply other threads:[~2026-05-21 7:53 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-17 20:01 [patch V6 00/16] Improve /proc/interrupts further Thomas Gleixner
2026-05-17 20:01 ` [patch V6 01/16] x86/irq: Optimize interrupts decimals printing Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Dmitry Ilvokhin
2026-05-17 20:01 ` [patch V6 02/16] genirq/proc: Avoid formatting zero counts in /proc/interrupts Thomas Gleixner
2026-05-19 21:24 ` Shrikanth Hegde
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:01 ` [patch V6 03/16] genirq/proc: Utilize irq_desc::tot_count to avoid evaluation Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:01 ` [patch V6 04/16] x86/irq: Make irqstats array based Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:01 ` [patch V6 05/16] x86/irq: Suppress unlikely interrupt stats by default Thomas Gleixner
2026-05-21 15:52 ` Shrikanth Hegde
2026-05-21 20:46 ` Thomas Gleixner
2026-05-23 17:48 ` Shrikanth Hegde
2026-05-24 12:37 ` Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:01 ` [patch V6 06/16] x86/irq: Move IOAPIC misrouted and PIC/APIC error counts into irq_stats Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 07/16] scripts/gdb: Update x86 interrupts to the array based storage Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 08/16] genirq: Expose nr_irqs in core code Thomas Gleixner
2026-05-19 21:29 ` Shrikanth Hegde
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 09/16] genirq/manage: Make NMI cleanup RT safe Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 10/16] genirq: Cache the condition for /proc/interrupts exposure Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 11/16] genirq: Calculate precision only when required Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 12/16] genirq/proc: Increase default interrupt number precision to four Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 13/16] genirq: Add rcuref count to struct irq_desc Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 14/16] genirq: Expose irq_find_desc_at_or_after() in core code Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 15/16] genirq/proc: Runtime size the chip name Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-17 20:02 ` [patch V6 16/16] genirq/proc: Speed up /proc/interrupts iteration Thomas Gleixner
2026-05-26 14:22 ` [tip: irq/core] " tip-bot2 for Thomas Gleixner
2026-05-18 3:54 ` [patch V6 00/16] Improve /proc/interrupts further mhklkml
2026-05-19 21:18 ` Shrikanth Hegde
2026-05-20 15:27 ` Thomas Gleixner
2026-05-21 4:34 ` Shrikanth Hegde
2026-05-21 7:53 ` Thomas Gleixner [this message]
2026-05-21 14:48 ` Shrikanth Hegde
2026-05-21 21:07 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jysxw65f.ffs@tglx \
--to=tglx@kernel.org \
--cc=d@ilvokhin.com \
--cc=florian.fainelli@broadcom.com \
--cc=jan.kiszka@siemens.com \
--cc=kbingham@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=mhklinux@outlook.com \
--cc=radu@rendec.net \
--cc=sshegde@linux.ibm.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox