linux-kernel - Re: [PATCH v3] sched/core: Tweak wait_task_inactive() to force dequeue sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250430134522.GA133753@pauld.westford.csb>
Date: Wed, 30 Apr 2025 09:45:22 -0400
From: Phil Auld <pauld@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
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 Wed, Apr 30, 2025 at 02:44:25PM +0200 Peter Zijlstra wrote:
> 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.
> 

I thought they "made a request" and got a slice when entering the
competition so would not immediately go negative when executing.
It's now been a while since I read the paper though...

Starting at 0 (service that it ought to have is none) and going
immediately negative seems to imply never having positive lag. But,
like I said, probably just misunderstanding something :)



Cheers,
Phil
--