[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YSfL3vdbuXWvI/Ya@hirez.programming.kicks-ass.net>
Date: Thu, 26 Aug 2021 19:14:06 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Juri Lelli <juri.lelli@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Steven Rostedt <rostedt@...dmis.org>,
Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] sched: Switch wait_task_inactive to HRTIMER_MODE_REL_HARD
On Thu, Aug 26, 2021 at 07:04:08PM +0200, Sebastian Andrzej Siewior wrote:
> With PREEMPT_RT enabled all hrtimers callbacks will be invoked in
> softirq mode unless they are explicitly marked as HRTIMER_MODE_HARD.
> During boot kthread_bind() is used for the creation of per-CPU threads
> and then hangs in wait_task_inactive() if the ksoftirqd is not
> yet up and running.
> The hang disappeared since commit
> 26c7295be0c5e ("kthread: Do not preempt current task if it is going to call schedule()")
>
> but enabling function trace on boot reliably leads to the freeze on boot
> behaviour again.
> The timer in wait_task_inactive() can not be directly used by a user
> interface to abuse it and create a mass wake up of several tasks at the
> same time leading to long sections with disabled interrupts.
> Therefore it is safe to make the timer HRTIMER_MODE_REL_HARD.
>
> Switch the timer to HRTIMER_MODE_REL_HARD.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Thanks!
Powered by blists - more mailing lists