From: Mark Rutland <mark.rutland@arm.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Petr Tesarik <ptesarik@suse.com>, linux-rt-users@vger.kernel.org
Subject: Re: Lazy preemption on arm64
Date: Tue, 17 Dec 2024 11:34:43 +0000 [thread overview]
Message-ID: <Z2Fh09GyYx09Mx1_@J2N7QTR9R3> (raw)
In-Reply-To: <20241217085031.Wh45Bd2r@linutronix.de>
On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> On 2024-12-17 07:31:51 [+0100], Petr Tesarik wrote:
> > V Mon, 16 Dec 2024 19:04:43 +0000
> > Mark Rutland <mark.rutland@arm.com> napsáno:
> >
> > > On Mon, Dec 16, 2024 at 07:04:51PM +0100, Petr Tesarik wrote:
> > > > Hi all,
> > > >
> > > > what is the plan for implementing PREEMPT_LAZY on arm64?
> > > >
> > > > There used to be RT patch series which enabled lazy preemption on
> > > > arm64, but this architecture was "sacrificed" in v6.6-rc6-rt10, as
> > > > collateral damage of switching to PREEMPT_AUTO.
> > > >
> > > > IIUC lazy preemption is currently implemented only for architectures
> > > > with CONFIG_GENERIC_ENTRY, but there is no inherent dependency on it.
> > > > So, is the plan to convert arm64 to GENERIC_ENTRY (and then get
> > > > PREEMPT_LAZY for free), or is somebody working on CONFIG_PREEMPT_LAZY
> > > > for arm64 without that conversion?
> > >
> > > I don't think there's an agreed upon plan either way.
> > >
> > > Jinjie Ruan has been looking to move arm64 over to GENERIC_ENTRY:
> > >
> > > https://lore.kernel.org/all/20241206101744.4161990-1-ruanjinjie@huawei.com/
> > >
> > > AFAICT, the only bits that we get "for free" from GENERIC_ENTRY would be
> > > the logic in raw_irqentry_exit_cond_resched() and
> > > exit_to_user_mode_loop(), and all we'd need to enable this on arm64
> > > as-is would be as below.
> >
> > @bigeasy: Would it be OK for you to add the below patch to the next
> > 6.13 RT patches?
>
> This bits below are actually the same ones I made last week. I stopped
> there because it was late and I didn't find GENERIC_ENTRY nor a
> TIF_NEED_RESCHED check in arm64 so I paused. Where is this?
Currently arm64 doesn't use GENERIC_ENTRY; people are working on that
(see the link above), but it's likely to take a short while. IIUC
there's no strict dependency on GENERIC_ENTRY here, unless I'm missing
something?
For TIF_NEED_RESCHED, arm64 relies upon the core code to call
set_preempt_need_resched() (e.g. via preempt_fold_need_resched()) to
fold that into thread_info::preempt::need_resched. That's checked by
arm64_preempt_schedule_irq(), which reads thread_info::preempt_count,
which is unioned with thread_info::preempt::{count,need_resched} such
that the two fields can be checked together.
> Other than that I would be happy to take it then hoping arm64 does the
> same.
If PREEMPT_LAZY is something that people need urgently then I can go
turn the hack into a proepr patch and see if we can queue that ahead of
the larger rework for GENERIC_ENTRY.
> > Mark tagged it with "HACK", but to me it actually looks just as good as
> > the good old (pre-PREEMPT_AUTO) arm64 patch. ;-)
>
> The old lazy-preempt had also tweaks in should_resched() and
> __preempt_count_dec_and_test(). So it is slightly different.
Hmm... what needed to change there?
Currently we're relying on the union trick to check both
thread_info::preempt::{count,need_resched}, where the latter should have
TIF_NEED_RESCHED folded in (but not TIF_NEED_RESCHED_LAZY), which IIUC
is sufficient?
Mark.
next prev parent reply other threads:[~2024-12-17 11:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-16 18:04 Lazy preemption on arm64 Petr Tesarik
2024-12-16 19:04 ` Mark Rutland
2024-12-17 0:40 ` gene heskett
2024-12-17 6:03 ` Petr Tesarik
2024-12-17 6:31 ` Petr Tesarik
2024-12-17 8:50 ` Sebastian Andrzej Siewior
2024-12-17 11:34 ` Mark Rutland [this message]
2024-12-17 11:59 ` Sebastian Andrzej Siewior
2024-12-17 12:23 ` Mark Rutland
2024-12-17 12:56 ` Sebastian Andrzej Siewior
2025-02-14 7:34 ` Mike Galbraith
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=Z2Fh09GyYx09Mx1_@J2N7QTR9R3 \
--to=mark.rutland@arm.com \
--cc=bigeasy@linutronix.de \
--cc=linux-rt-users@vger.kernel.org \
--cc=ptesarik@suse.com \
/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