From: Vishal Chourasia <vishalc@linux.ibm.com>
To: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Juri Lelli <juri.lelli@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
Valentin Schneider <vschneid@redhat.com>,
luis.machado@arm.com
Subject: Re: sched/fair: Kernel panics in pick_next_entity
Date: Tue, 1 Oct 2024 19:38:40 +0530 [thread overview]
Message-ID: <ZvwCaKkgb2F6pzLP@linux.ibm.com> (raw)
In-Reply-To: <55a2acefffb8c99e4234bd18656a75625447c2d0.camel@gmx.de>
On Tue, Oct 01, 2024 at 10:30:26AM +0200, Mike Galbraith wrote:
> On Tue, 2024-10-01 at 00:45 +0530, Vishal Chourasia wrote:
> > >
> > for sanity, I ran the workload (kernel compilation) on the base commit
> > where the kernel panic was initially observed, which resulted in a
> > kernel panic, along with it couple of warnings where also printed on the
> > console, and a circular locking dependency warning with it.
> >
> > Kernel 6.11.0-kp-base-10547-g684a64bf32b6 on an ppc64le
> >
> > ------------[ cut here ]------------
> >
> > ======================================================
> > WARNING: possible circular locking dependency detected
> > 6.11.0-kp-base-10547-g684a64bf32b6 #69 Not tainted
> > ------------------------------------------------------
>
> ...
>
> > --- interrupt: 900
> > se->sched_delayed
> > WARNING: CPU: 1 PID: 27867 at kernel/sched/fair.c:6062 unthrottle_cfs_rq+0x644/0x660
>
> ...that warning also spells eventual doom for the box, here it does
> anyway, running LTPs cfs_bandwidth01 testcase and hackbench together,
> box grinds to a halt in pretty short order.
>
> With the patchlet below (submitted), I can beat on box to my hearts
> content without meeting throttle/unthrottle woes.
>
> sched: Fix sched_delayed vs cfs_bandwidth
>
> Meeting an unfinished DELAY_DEQUEUE treated entity in unthrottle_cfs_rq()
> leads to a couple terminal scenarios. Finish it first, so ENQUEUE_WAKEUP
> can proceed as it would have sans DELAY_DEQUEUE treatment.
>
> Fixes: 152e11f6df29 ("sched/fair: Implement delayed dequeue")
> Reported-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
> Tested-by: Venkat Rao Bagalkote <venkat88@linux.vnet.ibm.com>
> Signed-off-by: Mike Galbraith <efault@gmx.de>
Hello Mike, Thank you the patch!
With the below changes, I don't see any warnings been printed on the
console, along with it, there were no kernel panics
Tested-by: Vishal Chourasia <vishalc@linux.ibm.com>
> ---
> kernel/sched/fair.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -6058,10 +6058,13 @@ void unthrottle_cfs_rq(struct cfs_rq *cf
> for_each_sched_entity(se) {
> struct cfs_rq *qcfs_rq = cfs_rq_of(se);
>
> - if (se->on_rq) {
> - SCHED_WARN_ON(se->sched_delayed);
> + /* Handle any unfinished DELAY_DEQUEUE business first. */
> + if (se->sched_delayed) {
> + int flags = DEQUEUE_SLEEP | DEQUEUE_DELAYED;
> +
> + dequeue_entity(qcfs_rq, se, flags);
> + } else if (se->on_rq)
> break;
> - }
> enqueue_entity(qcfs_rq, se, ENQUEUE_WAKEUP);
>
> if (cfs_rq_is_idle(group_cfs_rq(se)))
>
next prev parent reply other threads:[~2024-10-01 14:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-26 12:42 sched/fair: Kernel panics in pick_next_entity Vishal Chourasia
2024-09-26 14:31 ` Luis Machado
2024-09-30 14:41 ` Peter Zijlstra
2024-09-30 19:05 ` Vishal Chourasia
2024-09-30 19:15 ` Vishal Chourasia
2024-10-01 8:30 ` Mike Galbraith
2024-10-01 14:08 ` Vishal Chourasia [this message]
2024-10-01 16:41 ` Mike Galbraith
2024-10-02 6:40 ` Mike Galbraith
2024-10-02 8:49 ` Peter Zijlstra
2024-10-02 18:22 ` Vishal Chourasia
2024-10-02 22:31 ` Benjamin Segall
2024-10-03 4:41 ` Mike Galbraith
2024-10-03 9:31 ` Mike Galbraith
2024-10-04 7:17 ` Vishal Chourasia
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=ZvwCaKkgb2F6pzLP@linux.ibm.com \
--to=vishalc@linux.ibm.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luis.machado@arm.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.