[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230308091458.Q42uCjR2@linutronix.de>
Date: Wed, 8 Mar 2023 10:14:58 +0100
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: Petr Malat <oss@...at.biz>
Cc: linux-kernel@...r.kernel.org, paulmck@...nel.org,
tglx@...utronix.de, nsaenzju@...hat.com, frederic@...nel.org
Subject: Re: [PATCH] softirq: Do not loop if running under a real-time task
On 2023-03-06 16:45:48 [+0100], Petr Malat wrote:
> Softirq processing can be a source of a scheduling jitter if it executes
> in a real-time task as in that case need_resched() is false unless there
> is another runnable task with a higher priority. This is especially bad
> if the softirq processing runs in a migration thread, which has priority
> 99 and usually runs for a short time.
>
> One option would be to not restart the softirq processing if there is
> another runnable task to allow the high prio task to finish and yield the
> CPU, the second one is to not restart if softirq executes in a real-time
> task. Usually, real-time tasks don't want to be interrupted, so implement
> the second option.
This affects only PEEMPT_RT, right?
I have plans to redo parts of it. You shouldn't enter ksoftirqd to be
begin with. There is this ktimerd in v6.1 which mitigates this to some
point and I plan to extend it to also cover the sched-softirq.
Other than that, you are right in saying that the softirq must not
continue with a RT prio and that need_resched() is not visible here.
However ksoftirqd itself must be able to do loops unless the
need-resched flag is seen.
Since you mentioned migration thread, how ofter to you see this or how
does this trigger?
> Signed-off-by: Petr Malat <oss@...at.biz>
Sebastian
Powered by blists - more mailing lists