Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 1 Oct 2022 00:53:20 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Vincent Guittot <vincent.guittot@linaro.org>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Tim Chen <tim.c.chen@intel.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Juri Lelli <juri.lelli@redhat.com>,
        Rik van Riel <riel@surriel.com>,
        Aaron Lu <aaron.lu@intel.com>,
        Abel Wu <wuyun.abel@bytedance.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Yicong Yang" <yangyicong@hisilicon.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        Ingo Molnar <mingo@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        Daniel Bristot de Oliveira <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] sched/fair: Choose the CPU where short task is
 running during wake up
Message-ID: <YzcfAOLswvY05s0n@chenyu5-mobl1>
References: <20220915165407.1776363-1-yu.c.chen@intel.com>
 <CAKfTPtD3L4437htX__mCNBZJ+fv4MEdnNhCG2kBoQYhVESB_fg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAKfTPtD3L4437htX__mCNBZJ+fv4MEdnNhCG2kBoQYhVESB_fg@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/zC9D5c6HC5bHVWo8t1DcwHPhxqhHjCi9ZKTX4+qCqaJ46i6OBiREFqsiWXF?=
 =?us-ascii?Q?0loJmejq8y0WSuYJ9Uydezuuv901GBxfz+XTFn8vxyNGz3L0QKKAuqH0roG8?=
 =?us-ascii?Q?DtqS/tt4aYAhV+FHUeSwVFG0o1KGr7dkEYpFIjA3rCfoGuvbcUputOvnzX7u?=
 =?us-ascii?Q?oyYY9ED7URSTH9DCxEZyFPgjh5SX0v2Xnhy7D8e5+UwwOcJ9kKe4bXoNLKmM?=
 =?us-ascii?Q?8yPIZ7SWCd6+EQQl953QmkAx/JqMxuB3yn0B7sUoHGyzGuX2JFnn8nCOx5r/?=
 =?us-ascii?Q?KSKqlFIjfqrAve2Nd2RlT+FR3JQmEnVnFsuScbEb103FxaP4RjrMDZEvxA1W?=
 =?us-ascii?Q?9VRQXe/fYkv862jEZw7NpYlg5WHk5KawRQiwCzkYjWTRHQJZ7XbBhiaUht3l?=
 =?us-ascii?Q?mG4WTDtANvcElA8cFbIKvtAF7eLGhFb3iBP1W85vOwTM6OIUFALSCeUOEOHl?=
 =?us-ascii?Q?XzSppI3U3np2BWli9ygIpmDyKOiygV7jUr/NxPRRMOH4+YuXIco1z2o/mVCc?=
 =?us-ascii?Q?liabC24a8nWc1sTWKUtknflW/lCPh6QVAJe+ShKdSc/T0OHa7qqCtK8L27By?=
 =?us-ascii?Q?i+M0yZ9lIy01Takk95XcUWYxAh/Zw60W+nJqrNB+mbnjuA1DlkMmKfySibnr?=
 =?us-ascii?Q?zRTxZ9FaJwDJAL2ltZO80/e3rtcmugXOL3duioRi1AZ3O6xuAaQHwkxtsmnW?=
 =?us-ascii?Q?GYzOSLlaK40H+9IIonwoLPkauT5G/WlYWBGZ1ZN4ACq77wimAOqmyQ17vpUS?=
 =?us-ascii?Q?mK3j/gl2AGsM8+1tZNHAvERSlK6Z4kbmER/9ELDZnFXt/ehuUyyOlwqfAjwt?=
 =?us-ascii?Q?YwNCLScnS5d0MTwW0WBKcDly/7GOGdHqv892Fb8kMBBYoK2XiqzsOhWcfX6A?=
 =?us-ascii?Q?V60lYjNTWVyWltrJpdA7V61kJ/WTvglTTZ2Z/D7VNGeCngzuuYMOvDmWrwOu?=
 =?us-ascii?Q?uwp53MRUvhBcRiTcg47qNyLnyEjHxLzOLjO1WJDgcVo3Og/r5AtdKXIGYjux?=
 =?us-ascii?Q?NpxHLK++Q3qCmoTsXYMw9ue5VwhqO+Vtggi/tvxPq2dPVTAQ6lTYqMm9FXCR?=
 =?us-ascii?Q?8wCNVtZ1kMLTICWeIqMZmQmivPy36hNlgJG3uclusGh+yCx3zb/jvDfHevub?=
 =?us-ascii?Q?OIHIGhV927Gw8jguNnsqX0eFwcil4pB/MXpRURY64L4ERbCSd0sC8uUhS9hA?=
 =?us-ascii?Q?FTBrKIZO+zxphzUu7H6HRh3cG4TXw8U31f26heS2kxkd7XaG8oFH/iRdYVaT?=
 =?us-ascii?Q?FwuNHbBdyo5SyWxWY0kREkWLGmDdUyRTlcUxcKTU74Dz0nNV0DUDjoRPZ6HW?=
 =?us-ascii?Q?sd5uu82VoCJOfS+Aa2Jp5/ymQpq1SOmjLvPrCiok+b+MyqJnrtTJjgz67hfG?=
 =?us-ascii?Q?TMuJanTVyzNxsn6vv0MhYFf7OQ7+yAZbGoQkxaQ4p3Kzp/ItxPSws7wQWQ2C?=
 =?us-ascii?Q?c0/xVS4p7u102cNe3ostYXbwcRJVNFGMUpASDqdYOi3FVl1aFiIYSkXkA8zT?=
 =?us-ascii?Q?BIa1d+KO9NLLjnN/bVJ/W2eblNnoL5DMjARA0+VSU5UxcMdvtVCiNJoACzcN?=
 =?us-ascii?Q?W5xNQTy5a0WtuU2tDNdG6e6FvV+ENeDkPHUx/oac?=
X-MS-Exchange-CrossTenant-Network-Message-Id: af5174b3-6ec7-4fbd-157b-08daa304537c
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Sep 2022 16:53:40.6714
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 6azrVRn16gPJexaxREzRvmRtVBia2H+CkAtsKymBRwbPcsxMZ0tGIDtZXeEheKJLkSqAne3HrunvT/IcDkmfDg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB6434
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Vincent,
On 2022-09-29 at 10:00:40 +0200, Vincent Guittot wrote:
[cut]
> >
> > This idea has been suggested by Rik at LPC 2019 when discussing
> > the latency nice. He asked the following question: if P1 is a small-time
> > slice task on CPU, can we put the waking task P2 on the CPU and wait for
> > P1 to release the CPU, without wasting time to search for an idle CPU?
> > At LPC 2021 Vincent Guittot has proposed:
> > 1. If the wakee is a long-running task, should we skip the short idle CPU?
> > 2. If the wakee is a short-running task, can we put it onto a lightly loaded
> >    local CPU?
> 
> When I said that, I had in mind to use the task utilization (util_avg
> or util_est) which reflects the recent behavior of the task but not to
> compute an average duration
> 
Ah I see. However there is a scenario(will-it-scale context switch sub-test)
that, if task A is doing frequent ping-pong context switch with task B on one
CPU, we should avoid cross-CPU wakeup, by placing the wakee on the same CPU
as the waker. Since util_avg/est might be high for both waker and wakee,
we use the average duration to detect this scenario.
> >
> > Current proposal is a variant of 2:
> > If the target CPU is running a short-time slice task, and the wakee
> > is also a short-time slice task, the target CPU could be chosen as the
> > candidate when the system is busy.
> >
> > The definition of a short-time slice task is: The average running time
> > of the task during each run is no more than sysctl_sched_min_granularity.
> > If a task switches in and then voluntarily relinquishes the CPU
> > quickly, it is regarded as a short-running task. Choosing
> > sysctl_sched_min_granularity because it is the minimal slice if there
> > are too many runnable tasks.
> >
[cut]
> >
> > +/*
> > + * If a task switches in and then voluntarily relinquishes the
> > + * CPU quickly, it is regarded as a short running task.
> > + * sysctl_sched_min_granularity is chosen as the threshold,
> > + * as this value is the minimal slice if there are too many
> > + * runnable tasks, see __sched_period().
> > + */
> > +static int is_short_task(struct task_struct *p)
> > +{
> > +       return (p->se.sum_exec_runtime <=
> > +               (p->nvcsw * sysctl_sched_min_granularity));
> 
> you assume that the task behavior will never change during is whole life time
>
I was thinking that the average running time of a task could slowly catch
up with the latest task behavior, but yes, there would be delay especially
for rapid changing tasks(and similar to rq->avg_idle). I wonder if we
could use something like: 
	return (p->se.avg.util_avg <=
		(p->nvcsw * PELT(sysctl_sched_min_granularity));
to reflect the recent behavior of the task.

thanks,
Chenyu