From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 6907C331EC0 for ; Thu, 20 Aug 2026 07:19:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787210349; cv=none; b=W9HCv2igIn6HGWg82vXN8JXP8Eibx7W3CXz7Orbfn78H/947qRZA0qAPgTCOazW1j6YNC+eHtjQ2EBGtQ+jjOvITFQlMOiqI7FY6DKLsjwqN/+qN/HyJTVIz5g2QTPp/I3ISKvOPnfC/DLs4/JGAsPfB4PBCqN2qKjVRI8dubkI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787210349; c=relaxed/simple; bh=8PAjCpK1YZg/XlrBMZKqgANnRb4SM4XkhIp6kNvxtjY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X1nJ7NORdGC1Zo3WgBFs8pwUDEB1HzpYrwQimm1BlOGxoaxqywzljvhqz20DVlNP3OKxhZti0VGs2a09m2BpgJ8Qiyo21mWyvWLK3NDKxvdNye878qZ9/lNvNkw0C3dVvqQEFCH4jys+UQwH1y11l4R2ONcqlT+eVjRyra3x/K0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=LEcNubWn; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="LEcNubWn" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=OWW4No1FLczBHXXJ5ihGP/Nip12mVb4cQxr1W5td2uo=; b=LEcNubWnGLbFworT9DuT0nwjSe +s5jbT/NFqFl1W3h4D/qJPey3bEgLIpk4YP2lBFlQavpYZlbuQx4qgSN4RfLdIbToaQxe9ZlzyjUn jBO6XZIWyMeP0NWaCS41Nz2JQy0EA8NQdHJS+51t35/8nwxV8bqdaNmjQuz1C9RIRkwPrbJFtNNWr rypeZPKSFF5kuFnJzB1Nv/MjSnhZf3WaV9g5GY/Z/Mo/vp9uBeqCK0tMa58sN5EDc8U0wjLIMs+AH 0Rce9iGUYt8uvTzcXCGh512bdJ64yrxHwhWZ4otU2tkPZhjZbSgBo9r5dtGiA2uumfLeXuFTWIZsP KF9UvvYg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1wwx38-00000002ubJ-20Yd; Thu, 20 Aug 2026 07:18:54 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id F1E4C3006FA; Thu, 20 Aug 2026 09:18:52 +0200 (CEST) Date: Thu, 20 Aug 2026 09:18:52 +0200 From: Peter Zijlstra To: Tejun Heo 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: <20260820071852.GJ1247881@noisy.programming.kicks-ass.net> 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: On Wed, Aug 19, 2026 at 09:22:04AM -1000, Tejun Heo wrote: > 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. Right, but I worry about the cases: - there is no ext task pulled to local because $reasons (could be cpumask), and we retry, then it will see there are ext tasks, but no local and it will try again? - custom DSQs, those BPF based things, then we always need to drop the lock in order to execute those BPF methods, no? That is not unlike the case where fair has no local tasks and it will try and pull some tasks. It will try this every time, and if there are very few fair tasks in the system, this happens again and again. As mentioned, one 'hack' I considered was keeping a retry count, and simply setting 'rf = NULL' after a few cycles, to inhibit any further balancing and forcing progress. It just needs making sure all the sched_class::pick_task methods can deal with !rf, but that shoulnd't be too hard. > > 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? Indeed. Obviously idle doesn't do balancing, so its trivially correct, but it is indeed to make clear this is after seq validation.