[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250430124425.GN4439@noisy.programming.kicks-ass.net>
Date: Wed, 30 Apr 2025 14:44:25 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Phil Auld <pauld@...hat.com>
Cc: John Stultz <jstultz@...gle.com>, LKML <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>,
Valentin Schneider <vschneid@...hat.com>,
K Prateek Nayak <kprateek.nayak@....com>, kernel-team@...roid.com,
peter-yc.chang@...iatek.com
Subject: Re: [PATCH v3] sched/core: Tweak wait_task_inactive() to force
dequeue sched_delayed tasks
On Tue, Apr 29, 2025 at 11:36:05AM -0400, Phil Auld wrote:
> Hi John,
>
> On Tue, Apr 29, 2025 at 08:07:26AM -0700 John Stultz wrote:
> > It was reported that in 6.12, smpboot_create_threads() was
> > taking much longer then in 6.6.
> >
> > I narrowed down the call path to:
> > smpboot_create_threads()
> > -> kthread_create_on_cpu()
> > -> kthread_bind()
> > -> __kthread_bind_mask()
> > ->wait_task_inactive()
> >
> > Where in wait_task_inactive() we were regularly hitting the
> > queued case, which sets a 1 tick timeout, which when called
> > multiple times in a row, accumulates quickly into a long
> > delay.
> >
> > I noticed disabling the DELAY_DEQUEUE sched feature recovered
> > the performance, and it seems the newly create tasks are usually
> > sched_delayed and left on the runqueue.
>
> This seems odd to me. Maybe I'm just misunderstanding something but
> I don't see how newly created tasks should have accumulated enough
> runtime to have negative lag that needs to be decayed.
>
> That said, I think it does make sense to dequeue in this case.
Well, they start at 0, any runtime will likely push them negative.
Powered by blists - more mailing lists