From: "Brandt, Oliver - Lenze" <oliver.brandt@lenze.com>
To: "bigeasy@linutronix.de" <bigeasy@linutronix.de>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"peterz@infradead.org" <peterz@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] irq_work: Avoid unnecessary "IRQ work" interrupts
Date: Wed, 28 Aug 2024 14:52:17 +0000 [thread overview]
Message-ID: <2f59d15b63bfe1911261af86991820aadaf54b38.camel@lenze.com> (raw)
In-Reply-To: <20240828140223.P5vGN54Q@linutronix.de>
On Wed, 2024-08-28 at 16:02 +0200, bigeasy@linutronix.de wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> On 2024-08-28 13:26:42 [+0000], Brandt, Oliver - Lenze wrote:
> > Hmm.... I see. What about calling wake_irq_workd() directly; something
> > like
> >
> > if (rt_lazy_work)
> > wake_irq_workd();
> > else if (!lazy_work || tick_nohz_tick_stopped())
> > irq_work_raise(work);
>
> this might work but I'm not too sure about it. This will become a
> problem if irq_work_queue() is invoked from a path where scheduling is
> not possible due to recursion or acquired locks.
>
> How much of a problem is it and how much you gain by doing so?
>
To be honest I haven't made any measurements. But we have a system with
*very* tight timing constrains: One thing is a 16kHz irq; the other a
4kHz RT-task; both running on an isolated core. So if we assume ~2us
"overhead" for an irq (this should be more or less the time on our
system; Cortex-A9 with 800MHz) we would spend ~1% of our 250us grid for
the additionally irq. Not really something we would like.
Additionally we may get an (additionally) latency of ~2us before our 16-
kHz irq could go to work. Also something we wouldn't like.
What I didn't understand: The "IRQ work" irqs are needed in order to
start the execution of something. Ok. But how was this done before? It
seems that "softirqs" were used for this purpose on kernel v4.14 (don't
ask why we are using such an old version). But I didn't get the idea of
these "softirqs". Are they triggered via "real" irqs (e.g. IPIs)? In
this case we would most likely have the same count of irqs on a kernel
4.14 and a kernel 6.1 (our goal for now; I don't lose hope that even a
v6.6 may be used the next year).
Any ideas about this assumption?
> > Sebastian
Oliver
next prev parent reply other threads:[~2024-08-28 14:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 15:45 Brandt, Oliver - Lenze
2024-08-28 9:37 ` Sebastian Andrzej Siewior
2024-08-28 9:54 ` Sebastian Andrzej Siewior
2024-08-28 13:26 ` Brandt, Oliver - Lenze
2024-08-28 14:02 ` bigeasy
2024-08-28 14:52 ` Brandt, Oliver - Lenze [this message]
2024-09-03 9:26 ` bigeasy
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=2f59d15b63bfe1911261af86991820aadaf54b38.camel@lenze.com \
--to=oliver.brandt@lenze.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.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®