Greetings,
On Tue, 2024-12-17 at 12:23 +0000, Mark Rutland wrote:
> On Tue, Dec 17, 2024 at 12:59:31PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2024-12-17 11:34:43 [+0000], Mark Rutland wrote:
> > > On Tue, Dec 17, 2024 at 09:50:31AM +0100, Sebastian Andrzej Siewior wrote:
> > > > 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?
> >
> > No, not really, that is perfect.
> >
> > > 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.
> >
> > All sounds fine. Now, if that bit is set, we need schedule() before
> > returning to userland. I didn't it initially but now I did:
> >
> > diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> > index b260ddc4d3e9a..2e2f13ce076da 100644
> > --- a/arch/arm64/kernel/entry-common.c
> > +++ b/arch/arm64/kernel/entry-common.c
> > @@ -132,7 +132,7 @@ static void do_notify_resume(struct pt_regs *regs, unsigned long thread_flags)
> > do {
> > local_irq_enable();
> >
> > - if (thread_flags & _TIF_NEED_RESCHED)
> > + if (thread_flags & _TIF_NEED_RESCHED | _TIF_NEED_RESCHED_LAZY)
> > schedule();
> >
> > if (thread_flags & _TIF_UPROBE)
> >
> > With that piece we should be fine.
>
> Yep, I had that in my HACK patch:
>
> https://lore.kernel.org/linux-rt-users/20241217115931.wjw_HO2V@xxxxxxxxxxxxx/T/#m12eece66786a3a207e4e952bdf58570ab75c6a89
Posting this for mainline inclusion was suggested, but I don't see
waiting for GENERIC_ENTRY as having any meaningful impact for the
general case, everyone's used to whatever preemption model they've been
using. OTOH, not having PREEMPT_LAZY for RT users has been having at
least some impact, which your patch can alleviate, so I'll post the
fixed up and lightly tested version here... including something
resembling a changelog in case anyone disagrees about submission, but
is too lazy to write the way better one they most definitely should :)
