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 CCD8C386438 for ; Fri, 3 Apr 2026 11:28:23 +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=1775215708; cv=none; b=SLaCa+zZBoBojQNmARLkAkhV/krPXszTEB6wHt98mq76IDfZBZKnuP7jH/JIxchU5POCelHA4RStCwHZ1u/rn9Osw3f0KmnxMxacVrdCO69YtPmuEWG2QcncCYSuhmFwUo3ES4O9TJWczh235+Z49vNFjyGvKgifc2NbSc/V21A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775215708; c=relaxed/simple; bh=UK9++qyXIH0yBtnZKnRjPY/iqp6v1WtY5Qe099GhTwc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cOCTOisi708aaqKvp8QZBHM99aoQEBSrI/YJfjK7i2RnLbjpwlBoYvsMNbsuGBB1R2Bs3egJtCNFdzv5xylQHOOQhAeAqNnIt+/aCjAfgqxdghk5hW+syiTjqqrClACv8T40SkZpZPiJjMQtyupwxeH0epQGl099GTcztss5K9k= 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=ok1L4pCS; 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=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="ok1L4pCS" 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=MItysBc6SA+5I+weZTPALrdvUBMmUV5czeZNw1fHmbE=; b=ok1L4pCSoqbB6OgLv+mzhoxc8j 70yvsNFfHJmn9B8whpgLv3vf2v391FOj7aShgYjgZWkcgDaLqOucyF1LZ/GjG54fLXhXWrh9CSJhG wOESvsch/Z3UN5spIjDKLMzuAUb1NIXR7p9UZKFWjnrxFp/VqCUJsr64SjOZWSRpEsjBS+f9pJHmQ 7vr6Pcnie5mayfHWlnZlbrLhfocAiRMdUeJP0WhSXmIMmlsHUeiypqReYQWhrWZvkA2fZyKZ1Fno1 V6/GcH0Kqn9uDaRv4ft9R6hqItIr76BRoeaLljj0x9KzvUItjLhoMKvZsex8dTXhcIZzkEuNjr0fF ES8Sw6mg==; 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.98.2 #2 (Red Hat Linux)) id 1w8ch9-000000042oP-34er; Fri, 03 Apr 2026 11:28:11 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 0ADF9300346; Fri, 03 Apr 2026 13:28:10 +0200 (CEST) Date: Fri, 3 Apr 2026 13:28:10 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: John Stultz , LKML , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Mel Gorman , Will Deacon , Waiman Long , Boqun Feng , "Paul E. McKenney" , Metin Kaya , Xuewen Yan , Thomas Gleixner , Daniel Lezcano , Suleiman Souhlal , kuyo chang , hupu , kernel-team@android.com Subject: Re: [PATCH v26 00/10] Simple Donor Migration for Proxy Execution Message-ID: <20260403112810.GG3738786@noisy.programming.kicks-ass.net> References: <36e96f87-a682-436e-aefc-13e2e5810019@amd.com> <20260327114844.GQ2872@noisy.programming.kicks-ass.net> <33e60181-1809-44e1-bc4c-8ac7f79d49d6@amd.com> <20260327160017.GK3738010@noisy.programming.kicks-ass.net> <1515d405-62fc-4952-842f-b69e2bf192c0@amd.com> <20260402155055.GV3738010@noisy.programming.kicks-ass.net> <20260403095225.GY3738010@noisy.programming.kicks-ass.net> <1d2d4596-93d6-4d87-babc-084b8d6c2d98@amd.com> 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: <1d2d4596-93d6-4d87-babc-084b8d6c2d98@amd.com> On Fri, Apr 03, 2026 at 03:55:22PM +0530, K Prateek Nayak wrote: > >> @@ -4256,6 +4277,15 @@ int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags) > >> */ > >> smp_cond_load_acquire(&p->on_cpu, !VAL); > >> > >> + /* > >> + * We never clear the blocked_on relation on proxy_deactivate. > >> + * If we don't clear it here, we have TASK_RUNNING + p->blocked_on > >> + * when waking up. Since this is a fully blocked, off CPU task > >> + * waking up, it should be safe to clear the blocked_on relation. > >> + */ > >> + if (task_is_blocked(p)) > >> + clear_task_blocked_on(p, NULL); > >> + > > > > Aah, yes! This is when find_proxy_task() hits deactivate() for us and we > > skip ttwu_runnable(). We still need to clear ->blocked_on. I wonder, should we have proxy_deactivate() do this instead? > > > >> cpu = select_task_rq(p, p->wake_cpu, &wake_flags); > >> if (task_cpu(p) != cpu) { > >> if (p->in_iowait) { > >> @@ -6977,6 +7007,10 @@ static void __sched notrace __schedule(int sched_mode) > >> switch_count = &prev->nvcsw; > >> } > >> > >> + /* See: https://github.com/kudureranganath/linux/commit/0d6a01bb19db39f045d6f0f5fb4d196500091637 */ > >> + if (!prev_state && task_is_blocked(prev)) > >> + clear_task_blocked_on(prev, NULL); > >> + > > > > This one confuses me, ttwu() should never results in ->blocked_on being > > set. > > This is from the signal_pending_state() in try_to_block_task() putting > prev to TASK_RUNNING while still having p->blocked_on. Ooh, I misread that. I saw that set_task_blocked_on_waking(, NULL) in there and though it would clear. Damn, sometimes reading is so very hard... Anyhow, with my changes on, try_to_block_task() is only ever called from __schedule() on current. This means this could in fact be clear_task_blocked_on(), right?