From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 84244EB64D0 for ; Tue, 13 Jun 2023 17:12:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237019AbjFMRM3 (ORCPT ); Tue, 13 Jun 2023 13:12:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45108 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230399AbjFMRMZ (ORCPT ); Tue, 13 Jun 2023 13:12:25 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8C709170E for ; Tue, 13 Jun 2023 10:12:24 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D0FBD1FB; Tue, 13 Jun 2023 10:13:08 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB0943F663; Tue, 13 Jun 2023 10:12:20 -0700 (PDT) Message-ID: Date: Tue, 13 Jun 2023 19:12:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v4 07/13] sched: Split scheduler execution context Content-Language: en-US To: John Stultz , LKML Cc: Peter Zijlstra , Joel Fernandes , Qais Yousef , Ingo Molnar , Juri Lelli , Vincent Guittot , Valentin Schneider , Steven Rostedt , Ben Segall , Zimuzo Ezeozue , Youssef Esmat , Mel Gorman , Daniel Bristot de Oliveira , Will Deacon , Waiman Long , Boqun Feng , "Paul E . McKenney" , kernel-team@android.com, Connor O'Brien References: <20230601055846.2349566-1-jstultz@google.com> <20230601055846.2349566-8-jstultz@google.com> From: Dietmar Eggemann In-Reply-To: <20230601055846.2349566-8-jstultz@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/06/2023 07:58, John Stultz wrote: > From: Peter Zijlstra > > Lets define the scheduling context as all the scheduler state in > task_struct and the execution context as all state required to run > the task. > > Currently both are intertwined in task_struct. We want to logically > split these such that we can run the execution context of one task > with the scheduling context of another. > > To this purpose introduce rq_selected() macro to point to the > task_struct used for scheduler state and preserve rq->curr to > denote the execution context. > > NOTE: Peter previously mentioned he didn't like the name > "rq_selected()", but I've not come up with a better alternative. > I'm very open to other name proposals. > > Question for Peter: Dietmar suggested you'd prefer I drop the > conditionalization of the scheduler context pointer on the rq > (so rq_selected() would be open coded as rq->curr_sched or > whatever we agree on for a name), but I'd think in the > !CONFIG_PROXY_EXEC case we'd want to avoid the wasted pointer > and its use (since it curr_sched would always be == curr)? > If I'm wrong I'm fine switching this, but would appreciate > clarification. IMHO, keeping both, rq->curr and rq->proxy (latter for rq->curr_sched) would make it easier to navigate through the different versions of this patch-set while reviewing. I do understand that you have issues with the function name proxy() not returning the proxy (task blocked on a mutex) but the mutex owner instead. The header of v3 'sched: Add proxy execution' https://lkml.kernel.org/r/20230411042511.1606592-12-jstultz@google.com mentions: " ... Potential proxies (i.e., tasks blocked on a mutex) are not dequeued, so, if one of them is actually selected by schedule() as the next task to be put to run on a CPU, proxy() is used to walk the blocked_on relation and find which task (mutex owner) might be able to use the proxy's scheduling context. ..." But as I can see now, you changed this patch header in v4 to explain the PE model slightly differently. [...]