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 E0C8A3C276D for ; Thu, 20 Aug 2026 07:42:15 +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=1787211737; cv=none; b=jpNHZsA+tgjw1nBijB9cmhp/DUiqiivLfbtBGmrN6K7tV6/JtXR3R+f54AMOzZsze666kOmzm6XoUirggWI3dKFIK/ycPySvKpI5tAbaHNyqOLY9QSbdqhyJuJweXsUehsKdhzZytRpnpRxxsdogAsHmZZPK+CTXBs+FdRqUiJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787211737; c=relaxed/simple; bh=kU02CJA2atgKHz8/p39g/Scd4aVxLwu8NTGIdO9GaM8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gS6rnMKAA4OiaLTvZtdgwQE95Ndq2FGwobeXLn32cRO3U9ak0AaPCKaQ/7oYnxc78A4Fd3EGhEM31AYh8l01rMp94x2/hvq+u4Fmwv1IW6oOQgrFLX7jfp3B1m7iynvBctN6gh3VlkK/sHprqvGsOlN1Ay+IpYMxg3v70V/mmE0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gnvIVcWK; 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="gnvIVcWK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14D591F000E9; Thu, 20 Aug 2026 07:42:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787211735; bh=wDMhXS+YMOP0/b0kNljqFBi/wMJaKCg5VZhtTOumuAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gnvIVcWKauH2xlbm0/vOpH3X2Qt7ACyjp/sAfZiaOX+V61f1cLVsAHul0vJ/Bixhh g8tmC4uyanxP9ZsV6OEok2ubsOgJrP0pnNm/JzFWGL9W/gPkSIDx0QJKe9pnJG78lX QaDNgpKONPJJ6VH7Sb5gu5Ch8xDDznlRc1MAWnYFNyJqYgeuXK4jrx/Cx+TLEIQd/e 5m8s/70RQpdhGz958SWeiOYl/lqEyoorR+JouKncJauyaiat2ZFO8uyUwVyqfTl7oB vejAT99zuo4eWPyLJSvAhWH2RSYL+bK+dobc/1WzbDx2BgngE5U58D59uPSN8fPsmM kFq0qrWQjpQkA== Date: Wed, 19 Aug 2026 21:42:14 -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> <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: <20260820071852.GJ1247881@noisy.programming.kicks-ass.net> 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. > - 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). Thanks. -- tejun