From: "David Wang" <00107082@163.com>
To: "Thomas Gleixner" <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/13] kernel/irq/proc: use seq_put_decimal_ull_width() for decimal values
Date: Thu, 14 Nov 2024 20:10:29 +0800 (CST) [thread overview]
Message-ID: <c975578.a64f.1932a950632.Coremail.00107082@163.com> (raw)
In-Reply-To: <87jzd7kl0v.ffs@tglx>
Hi,
At 2024-11-14 03:10:08, "Thomas Gleixner" <tglx@linutronix.de> wrote:
>On Sat, Nov 09 2024 at 00:07, David Wang wrote:
>> The improvement has pratical significance, considering many monitoring
>> tools would read /proc/interrupts periodically.
>
>I've applied this, but ...
>
>looking at a 256 CPU machine. /proc/interrupts provides data for 560
>interrupts, which amounts to ~1.6MB data size.
>
>There are 560 * 256 = 143360 interrupt count fields. 140615 of these
>fields are zero, which means 140615 * 11 bytes. That's 96% of the
>overall data size. The actually useful information is less than
>50KB if properly condensed.
>
>I'm really amused that people spend a lot of time to improve the
>performance of /proc/interrupts instead of actually sitting down and
>implementing a proper new interface for this purpose, which would make
>both the kernel and the tools faster by probably several orders of
>magnitude.
That's a great idea~.
I tried to make changes and verify the performance, the result is good,
only that kernel side improvement is not that big, but still significant.
Here is what I did, (draft codes are at the end):
Created two new /proc entry for comparision:
1. /proc/interruptsp, non-zero value only, arch-independent irqs without description
$ cat /proc/interruptsp
IRQ CPU counter # positive only
0 0 40
38 5 23
39 0 81
40 1 6
41 2 111
...
$ cat /proc/interruptsp | wc
18 57 181
$ strace -e read -T cat /proc/interruptsp > /dev/null
...
read(3, "IRQ CPU counter # positive only\n"..., 131072) = 181 <0.000144>
read(3, "", 131072) = 0 <0.000009>
$ time ./interruptsp # 1 million rounds of open/read(all)/close;
real 1m54.727s
user 0m0.368s
sys 1m54.309s
2. /proc/interruptso, same with old format, except arch-dependent irqs are removed
$ cat /proc/interruptso | wc
32 388 4439
$ strace -e read -T cat /proc/interruptso > /dev/null
...
read(3, " CPU0 CPU1 "..., 131072) = 4005 <0.000071>
read(3, " 88: 0 0 "..., 131072) = 434 <0.000111>
read(3, "", 131072) = 0 <0.000009>
$ time ./interruptso # 1 million rounds of open/read(all)/close;
real 2m19.284s
user 0m0.400s
sys 2m18.756s
The size is indeed tens of times shorter, and would have huge improvement
for those applications parsing the whole content; But as for kernel side
improvement, strace and stress test indicates the improvement is not
that huge, well, but still significant ~40%.
The bottleneck seems to be mtree_load called by irq_to_desc, based on a simple
profiling (not sure whether this is expected or not):
show_interruptsp(74.724% 845541/1131554)
mtree_load(56.596% 478544/845541)
__rcu_read_unlock(5.914% 50004/845541)
__rcu_read_lock(3.056% 25840/845541)
irq_to_desc(2.151% 18184/845541)
seq_put_decimal_ull_width(1.211% 10243/845541)
...
I think the improvement worth pursuing. Maybe a new interface for "active"
interrupts, say /proc/activeinterrupts?, and the old /proc/interrupts can
serve as a table for available ids/cpus/descriptions.
Do you plan to work on this? If not, I can take time on it.
Draft codes:
int show_interruptsp(struct seq_file *p, void *v)
{
int i = *(loff_t *) v, j;
struct irq_desc *desc;
if (i >= ACTUAL_NR_IRQS)
return 0;
/* print header and calculate the width of the first column */
if (i == 0) {
seq_puts(p, "IRQ CPU counter # positive only\n");
}
rcu_read_lock();
desc = irq_to_desc(i);
if (!desc || irq_settings_is_hidden(desc))
goto outsparse;
if (!desc->action || irq_desc_is_chained(desc) || !desc->kstat_irqs)
goto outsparse;
for_each_online_cpu(j) {
unsigned int cnt = desc->kstat_irqs ? per_cpu(desc->kstat_irqs->cnt, j) : 0;
if (cnt > 0) {
seq_put_decimal_ull(p, "", i);
seq_put_decimal_ull(p, " ", j);
seq_put_decimal_ull(p, " ", cnt);
seq_putc(p, '\n');
}
}
outsparse:
rcu_read_unlock();
return 0;
}
int show_interruptso(struct seq_file *p, void *v)
{
static int prec;
int i = *(loff_t *) v, j;
struct irqaction *action;
struct irq_desc *desc;
unsigned long flags;
if (i >= ACTUAL_NR_IRQS) <<---return when arch-independent irqs are done.
return 0;
...
Thanks~
David
next prev parent reply other threads:[~2024-11-14 12:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 16:07 David Wang
2024-11-13 16:44 ` [tip: irq/core] genirq/proc: Use " tip-bot2 for David Wang
2024-11-13 19:10 ` [PATCH 01/13] kernel/irq/proc: use " Thomas Gleixner
2024-11-14 12:10 ` David Wang [this message]
2024-11-19 19:55 ` Geert Uytterhoeven
2024-11-20 1:20 ` Thomas Gleixner
2024-11-20 1:36 ` David Wang
2024-11-20 4:24 ` David Wang
2024-11-26 17:40 ` Thomas Gleixner
2024-11-27 0:07 ` David Wang
2024-11-20 8:56 ` Geert Uytterhoeven
2024-12-03 10:40 ` [PATCH] genirq/proc: Add missing space separator back Thomas Gleixner
2024-12-03 11:19 ` David Wang
2024-12-03 11:21 ` [PATCH] " Geert Uytterhoeven
2024-12-03 13:56 ` Thomas Gleixner
2024-12-03 14:11 ` [tip: irq/urgent] " tip-bot2 for Thomas Gleixner
2024-11-20 1:37 ` [PATCH 01/13] kernel/irq/proc: use seq_put_decimal_ull_width() for decimal values David Wang
2024-11-20 2:08 ` David Wang
2024-11-20 9:00 ` Geert Uytterhoeven
2024-11-20 9:36 ` David Wang
2024-11-20 9:56 ` Geert Uytterhoeven
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=c975578.a64f.1932a950632.Coremail.00107082@163.com \
--to=00107082@163.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
/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
all inboxes | Powered by JetHome®