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 3DA223EB7FE for ; Thu, 2 Jul 2026 09:15:02 +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=1782983704; cv=none; b=dcXyALyMFb0fZ+jCbE4GztEowNAGUbfaFB5HYj1bEu8+BaFAxQch8SL3Ap9+A/iFfJdlK9znFybzJNG2Bt8c8Sr8aqC6owAv2zgTCnLNCZnBzC3MGSZN/HBz3LSUXAsrOuWJRG6ZE6s+Tu6lAtxderf5wYYcf+muLtY8ndugrB4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782983704; c=relaxed/simple; bh=gwImHS5OtTlEDXAEQ1ejjjDD1qcunABOx0mC7CNZOGU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iF5t+lr75NFG2EVqAphh2wK4Z4MbUWqwnh/c+0ARYOV8pI77T5bhtp6na5U6BAaSUIvt59lk4C4skBNKSKmktvRB+rZmJPmqCVCGRkOEl355vq+Qv/7sB5wlI6LGGRcf3kWXtjiy2pcEJoaQOGCihjHGpbbTYMd5YKYiRYC0RwI= 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=U04W74H0; 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="U04W74H0" 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=PA6z8JPaEfRmlu2ZYwNTm7XOqYb3X6YeGSafzpPZ6Ok=; b=U04W74H06h6/siOz8T9fGg2fx9 nZjxm0p4JWc1WBnumQJVRl82sSIkLMEA2OX/NV90Ifs/1ML10dYeya3VGn4Sc0mcNXt9IjLNCoqDz STKkeLWdAHrM5UUBc6unDA2Z+VSAod6gPN88awjqlj6Cg4TehMpOZeeHFtXp56/6RkDYGlKyduQA6 17HTlfKUJJZeZOJMES+9aCxfDiIHJKQKrnSyu3qO6/4INa2j7qRJjEaTbtD3oP8uyj5nPDxWWWc1R hWYFePFk0w26takDsJjdFIj0hO0LdZtxgNgHUxm1em8PKI1KQAlS0Mi2FTo1slw5WiZUG9ws+rKTP 1juUf4LA==; 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 1wfDVM-00000003bBX-1HDQ; Thu, 02 Jul 2026 09:14:44 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id E041F300402; Thu, 02 Jul 2026 11:14:42 +0200 (CEST) Date: Thu, 2 Jul 2026 11:14:42 +0200 From: Peter Zijlstra To: K Prateek Nayak Cc: John Stultz , LKML , Vasily Gorbik , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , 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 v30 3/7] sched/core: Don't proxy-exec unmatched cookie lock owners Message-ID: <20260702091442.GF751831@noisy.programming.kicks-ass.net> References: <20260701214615.3773339-1-jstultz@google.com> <20260701214615.3773339-4-jstultz@google.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: On Thu, Jul 02, 2026 at 10:43:14AM +0530, K Prateek Nayak wrote: > Hello John, > > On 7/2/2026 3:15 AM, John Stultz wrote: > > From: Vasily Gorbik > > > > Core scheduling chooses a core-wide cookie before __schedule() > > installs the next task. With proxy-exec enabled, that task becomes the > > donor/scheduling context, and find_proxy_task() may then replace the > > execution context with the runnable mutex owner. If its cookie differs > > from the selected core cookie, running it would bypass core scheduling's > > cookie selection. > > > > When the final mutex owner found by find_proxy_task() does not match the > > selected core cookie, stop proxying the donor. If the current execution > > context is already in the blocked chain, fall back to idle like the > > existing proxy-exec retry paths do. Otherwise deactivate the donor and > > let __schedule() pick again. The mutex owner can be picked later under > > its own cookie. > > So I had a interesting (maybe a bit insane) way to make this work by > using the lock owner for rq->core_cookie when the blocked donor is > the core-wide preferred selection. > > I was waiting on Peter's core-sched cleanup to post an official series > but it is currently present as one big RFC patch at > https://lore.kernel.org/lkml/9ceb2af0-33c6-40ca-b855-5167a9c5ae0f@amd.com/ > > I can streamline that more on top of current tip to do it all in > pick_next_task() but the bigger question is, is it worth all the > complexity? > > John, Peter, what do you think? I am going to excuse myself and say I'll look at all this in about 4 weeks when I'm back from holidays.