From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 AB87A3CF039 for ; Thu, 20 Aug 2026 07:58:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787212725; cv=none; b=NNujhA39T2B8Gus7Y7pisurFWaMUHGa9uQbTzW5SR5fQXwcK7iuBcLQ0waKNVv44HiStFw5m+9YWrSu2fJv17i5QZTPatwYtogB/EFZopTzEA5Gsn1eJj5alm+Z8CBYK6V71kdWxUGmzModXWMzyfvcWhDdjnU47oTvdTJEcgT4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787212725; c=relaxed/simple; bh=DAFEamT89OGhjI+sq4qMvO4ljBXaN9CsbwGiB9sbQVs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MIAxOPl+8nAp9vhLNdpoXZL8DcabQlQN14Db3viDegtSbHKBR0xwiAcK0PHLFRJA2NxR9xRSiRznfvY/ZTSWuZHn3pEZL1y1HPpD+5QO+MEwPUwSGeQaL5dfuPoXVTb6OJRUZwoXA1RflRvtko32qEigUFG7fSGKIdwIHEZmeHc= 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=Cdd9A3Wb; arc=none smtp.client-ip=90.155.50.34 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="Cdd9A3Wb" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=NfJc/m1mHhbhXXS6c8TBmXnLtgp1GNwi4elqYZZ7GZ0=; b=Cdd9A3WbKk/9bsIDt9BQOU5dLi ri4k1eZ3tE0C0dGCkZJbTdGnnK9vaY3jaT8nlEyfa4jwm5JPV2X5tk8RmNddMVzT2W8EofCv76gW/ 7+tIhqOxHZzw/ZXZnXLo/65GPiqXlYkYRzGXDyGy7omVNNnF2/c4NrUYWtlN0UamVSAU9OWMhyocj rscauf2KlNSYWwQgSyVFeLaN0thRXnVhacL6+/XpfoRfPl/zoRzRD5gciK3MiLmMlnbQcdPdHZi08 OSAkytecdYlSkpxGs4dY2jJGO5eT0CFfGureWdRA4/9VkHifAzP1cZe+T2H3pWhgLi5/uRyFl54UN TjIZ/xsg==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wwxfR-0000000F8TS-3Xuh; Thu, 20 Aug 2026 07:58:30 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 1CA0A3006FA; Thu, 20 Aug 2026 09:58:29 +0200 (CEST) Date: Thu, 20 Aug 2026 09:58:29 +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: <20260820075829.GI1246887@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> <20260820071852.GJ1247881@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:42:14PM -1000, Tejun Heo wrote: > Hello, Peter. > > On Thu, Aug 20, 2026 at 09:18:52AM +0200, Peter Zijlstra wrote: > ... > > 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? > > For SCX, rq lock is not dropped for "trying". It is only dropped when there > is a task to be migrated, so if nothing has changed since the last time, > there won't be a task to migrate and thus no lock drop. Hmm, right. I don't think I can get fair to behave that way in a hurry. Also, even if I could, the figuring out if there is anything to move might still be somewhat expensive to retry multiple times. Let me continue pondering if there is anything saner than simply clearing rf. > > - custom DSQs, those BPF based things, then we always need to drop the > > lock in order to execute those BPF methods, no? > > No, those all nest inside rq locks. Think about enqueue path. Enqueue needs > to run all those and we don't drop rq lock while enqueueing (unless we're > bouncing to another rq's local DSQ at least). Oh right.. bah, I keep forgetting how all that works :/