From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04745416D1B for ; Wed, 19 Aug 2026 19:22:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787167329; cv=none; b=EzL8fYHniF8waOg72lo/6lyczxNMvJ0OuAXd9BLGGT8JCa67cAZ+s9Yvlb9NegSeTaovKeMqIPQTM3f9K+98uQ3a0eFz2myoNYWQmbboUh1HpgiDshPmbfKjNBDgRvo7nZDLtupPX8b9g3bgH+IhJf9OUsR1AuzLtMiQ9S8agzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787167329; c=relaxed/simple; bh=eNpSCPpr6wE+yWrb08BgK/FZcqForBRJFTlGBmBlfio=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eu6G7D0powrT8iD2HGnIzzuorqiSZczrlm3RSrFPFidCUqBK/rQziJIhBVQGVYB35Lj2sJl8AAZEA2po7FgpkWCDDHkbFrWhCpp1zCIdGiC7hB0IaIumqR5WgGmlNYT4T1CLCHXo8zl7XcpqYcS8n6YLzVhyinwup/9cEQub6u0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EgGGHE+k; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EgGGHE+k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6A9D01F000E9; Wed, 19 Aug 2026 19:22:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787167325; bh=crtx9YmgXiWzS4huH+Y1qzYtnBykfT8qBNlsIFxq/Ag=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EgGGHE+kwcVfADAPR0o+8YGCOgX3xoZoi59y0pRK6ocP7FOWx3REdjL/QD8caJuUb g5abihm+NQzTqu2IIDavPnZWggNmEZvtet4Y8Z5/CTwfVjjD82aDhwio3o9E6cNHN9 0Raw/+JO+gbQklHSfi0WY3aaUytMOqs64VN0uj9yVWM1n6MnnmPLib3f2E+nYm2zgg c+6mWNMvtPMeMp57m3bIqeqyklWjcZq4KICAgt7aqBVkGaO4qsp+vydjUSaJjWKguY nlBVB2/SLZVBYwAl8TefFJDvsM9rHGNKHsXmLdg/6sii1qaZYq60RwEH5SWWAgUXdY A/VqijNKxwx7w== Date: Wed, 19 Aug 2026 09:22:04 -1000 From: Tejun Heo To: Peter Zijlstra Cc: Aaron Lu , mingo@kernel.org, linux-kernel@vger.kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, kprateek.nayak@amd.com, williams@redhat.com, jkacur@redhat.com Subject: Re: [PATCH 0/2] sched: Remove sched_class::balance() Message-ID: References: <20260624121327.190063948@infradead.org> <20260702114919.GA186418@bytedance.com> <20260819075830.GF1246887@noisy.programming.kicks-ass.net> <20260819143649.GB1248307@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260819143649.GB1248307@noisy.programming.kicks-ass.net> Hello, On Wed, Aug 19, 2026 at 04:36:49PM +0200, Peter Zijlstra wrote: ... > > Except that is susceptible to live-locks. It doesn't have forward > > progress guarantees. For that we need to limit the amount of > > lock-breaks/newidle invocations. > > So TJ did something like that for ext. I'm not entirely sure I get his > argument on forward progress though. For SCX, rq lock is dropped only when a task needs to be migrated to be put in the local DSQ and, barring something else happening to it like dequeue or competing dispatch, the next time pick_task comes around, the task is going to be on the local DSQ, and won't need to drop the lock for that rq and thus picking would be able to proceed to the next rq. > But the simple thing is something like so, which I think also allows > simplifying ext some. Oh yeah, if core_seq tracks competing multi-picks, SCX no longer needs to track lock drops which was kinda ugly. > @@ -6392,7 +6393,7 @@ pick_next_task(struct rq *rq, struct rq_flags *rf) > if (cookie) > p = sched_core_find(rq_i, cookie); > if (!p) > - p = idle_sched_class.pick_task(rq_i, rf); > + p = idle_sched_class.pick_task(rq_i, NULL); I guess this is to signify that idle pick shouldn't drop rq lock as it's after seq verification? Thanks. -- tejun