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 67C8C3E025C for ; Tue, 26 May 2026 11:37:25 +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=1779795447; cv=none; b=j7ikOyir2nt4UnjjEJoo5nUORcuJUv3UKt2nlckiRtDtIvhwxCzU/ulD2qbOuEFcyKT+1FwXq0lGwOCCswzaDTrmdUedsA93ysWfGB6VOGKjx7sfnJJQxZCJpXema+XevBHIFdknwFDOeWl2RRlwZye0v8MDK2ndNv6rwhRfMjE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779795447; c=relaxed/simple; bh=3TWObn5P/N8Z+2N1GCI+kOLJefa67JEMxT8xeOybhg0=; h=Message-ID:Date:From:To:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc: Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Subject; b=rzsGcunHKVc3NG1jUlbBA+XHPs8xgis5gNQfqGrQHizhs8C/vIwgp8Zf7/4lw5fRvW7wo7ipuDwrGUK8ltCwh0GRYmZ3RUhije92IMg4qA0zf05HzvEbGhHle8mf/33+HHBafNvu0Z2T1bexgSFhvzDLI8Mm0aPWV0RIUYONsAo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=A10FtAjX; 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=none 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="A10FtAjX" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Subject:Cc:To:From:Date:Message-ID: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:In-Reply-To:References; bh=3TWObn5P/N8Z+2N1GCI+kOLJefa67JEMxT8xeOybhg0=; b=A10FtAjXVLHrcT0kb4KVvlk1bK SN1C2weu8EYz2NWggtkBdCo58HPQWNATdrjvv23LDDcGl2a1b5kqa4F8fdFBZoYakFlAtEn9y93sK nzcbd+uWU0ZU4H8AfyF2vckXSpaLv2Q7l1qYOyORKD3pis2x/r2SZYGx3EPBy58b4LGMRb6MWMuNF D0LluokmAbyQ0cB2J+7CJ/JOulG2r3OvReonFCh0jZFI34Vd1gezJ70ypO3NgB5unVmsifn/yrLqi 0g/cNzaW1pTaMfsPKBghCqLkpGPNL8QqjBty40uVTsVC/U1KnlD0Akmv+b7xgLHFhcEnnUH+AX39u frpeQCyQ==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wRq5x-00000000zi6-2UHt; Tue, 26 May 2026 11:37:14 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 0) id 0469A300323; Tue, 26 May 2026 13:37:13 +0200 (CEST) Message-ID: <20260526111609.433880331@infradead.org> User-Agent: quilt/0.68 Date: Tue, 26 May 2026 13:16:09 +0200 From: Peter Zijlstra To: John Stultz , K Prateek Nayak Cc: Joel Fernandes Cc: Qais Yousef Cc: Ingo Molnar Cc: Juri Lelli Cc: Vincent Guittot Cc: Dietmar Eggemann Cc: Valentin Schneider Cc: Steven Rostedt Cc: Ben Segall Cc: Zimuzo Ezeozue Cc: Will Deacon Cc: Waiman Long Cc: Boqun Feng Cc: "Paul E. McKenney" Cc: Metin Kaya Cc: Xuewen Yan Cc: Thomas Gleixner Cc: Daniel Lezcano Cc: Suleiman Souhlal Cc: kuyo chang Cc: hupu Cc: linux-kernel@vger.kernel.org, peterz@infradead.org Cc: Mike Galbraith Subject: [PATCH 0/6] sched/proxy: doodles.. Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: This goes on top of queue:sched/proxy. I was trying to do some cleanups and playing around with that PROXY_WAKING removal, and also moving towards using ->is_blocked to replace the core se.sched_delayed usage. But aside from making a few silly mistakes and taking far too long to figure out WTF happened, I've ran into a snag with the scheme to remove PROXY_WAKING. This happens in patch #4, where we switch the proxy paths to be guarded by ->is_blocked, rather than ->blocked_on. This works fine for schedule() / pick_next_task, since that guarantees there are no delayed tasks. However ttwu_runnable() has no such luck, and if ->is_blocked is all we have, then it turns out that we'll always fully block delayed tasks and send then through the long path. Now, I did me some ttwu-delayed patches a while ago, and Mike has been poking me about them. Those patches pick out the delayed things before we take locks, so perhaps we can resolve this that way. I'll have to poke a bit more. In the meantime, I figured I'd share the patches I got... I think at least the first 3 might live :-)