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:   Fri, 6 Jan 2023 22:29:45 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Dietmar Eggemann <dietmar.eggemann@arm.com>
CC:     Peter Zijlstra <peterz@infradead.org>,
        Vincent Guittot <vincent.guittot@linaro.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>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        "Daniel Bristot de Oliveira" <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Hillf Danton <hdanton@sina.com>,
        Honglei Wang <wanghonglei@didichuxing.com>,
        Len Brown <len.brown@intel.com>,
        Chen Yu <yu.chen.surf@gmail.com>,
        "Tianchen Ding" <dtcccc@linux.alibaba.com>,
        Joel Fernandes <joel@joelfernandes.org>,
        Josh Don <joshdon@google.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v4 1/2] sched/fair: Introduce short duration task
 check
Message-ID: <Y7gwWUKyG+6OUYd9@chenyu5-mobl1>
References: <cover.1671158588.git.yu.c.chen@intel.com>
 <ec049fd9b635f76a9e1d1ad380fd9184ebeeca53.1671158588.git.yu.c.chen@intel.com>
 <82689dd6-9db1-dd00-069b-73a637a21126@arm.com>
 <Y7fdEruJGTux4fYH@chenyu5-mobl1>
 <1913041e-ee67-1e65-68fa-ef08b97ed9d5@arm.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1913041e-ee67-1e65-68fa-ef08b97ed9d5@arm.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Q4On1RYGqIV3myu2CexdtV/Nx4ucICK5dSvUmm1VNaHA4xYzmiHJ83Bnceem?=
 =?us-ascii?Q?4LabZoONRfuUNesUx8tZIPu52ApQBCN+hdiJ9iTA4sKgUC90f0QLMATtyEMS?=
 =?us-ascii?Q?RGAESUvffOYvunpZot9ztHRQzcErzcnqcYL3L5HvBz+/AaogcF41IfAAUYh3?=
 =?us-ascii?Q?IR8u494i134rJs0IPq5eHMvalLXuHyaDuCen9ZZRKuqxZTQvHQVGsCw+DK/n?=
 =?us-ascii?Q?ydGh75BDtaFP/2tgw1COc/WSYaZ2zwHSz9UXBrEN6NKjgQtab11ecJc/BR80?=
 =?us-ascii?Q?6bGpOU7BQyGRTCbSa6MDVRIgNBwOiMhOxtG2WHLAI6fxJJU3A7RW/gAlSWt0?=
 =?us-ascii?Q?UGYWMDK8CuG5bfG2c0xi81va9kcIk3QOQxAwRbMbY/k8haRRqEh6I7VuOzx8?=
 =?us-ascii?Q?4lt6s5m7Od0QzMD+Y8DI0LZvmo/kSciat2m9ZRO7OrqAqNiw9J5RZDOlOXRj?=
 =?us-ascii?Q?AkcNF6JCMhAVGGhj4newx8DntVI4CXUAm947GY2JAQJlRxNq3PMa1PmMkr/p?=
 =?us-ascii?Q?4aMMayso7BX60MHnbNcUtHhMsCKMEAb22WipJAso5XqUNIlYg5aT0ZKSZd3K?=
 =?us-ascii?Q?4BYxcTlmFRqUfnwURNlnT4NmXcFKk4zTSrJNTnUYP4BOMe3IOZtab4ToR/VM?=
 =?us-ascii?Q?QZYJ81nvzRWub/iEyd+Udtbfv4/OMUVFGcCrCakLuOQHWxAN/JJZ5j62wIGI?=
 =?us-ascii?Q?0kx2+RTydoWf1EBTLnTfPU+M/wtt5o0upOgNYJjidaNpsvyFAl6few2IeMRR?=
 =?us-ascii?Q?L+bKDCaun1nNXVursVsRCd8hvR1Ap8YQE8DR0qqezQePohu68QTSuuVmBldL?=
 =?us-ascii?Q?YkRiJhkRLRY7zDfEWw6amdo9BIFiq8X+PCg8WJ4oynlwIEOYeWJFDl3pGhtp?=
 =?us-ascii?Q?BKO+xTk66MVyspQJvrp41i0zHEDkADBROFAoyAXu8/IGKzGfdcwRwv/NwV6Q?=
 =?us-ascii?Q?QV7iHiJTXXHaQ1lp9++2w92pDrFmIumPUZywIC3x6RBQbOx0RR7AWB6q0RBV?=
 =?us-ascii?Q?Nm+cZaNOKl8kC0uzplKEVzZ1eFdOF7GEEbmvIl8+ddNOLXPu4OChF0j+byF4?=
 =?us-ascii?Q?PJoySFavyc6lYfh5VS0HFuSOIIfHSfLdrqFkVFUwXQStZgGqiY7ZzmoVzXdt?=
 =?us-ascii?Q?EIomOCDxDnY5AQMkwfKspF8aHSVgh7q6K7NAcfzS24OlU3DuguQ5GIxbQMuw?=
 =?us-ascii?Q?xA/xI7zk8FS0myy0XV79ERmBA7NjP9+mBGtHptE29wz9aBDvTOTR+OCinme9?=
 =?us-ascii?Q?YUrmixs4/RxTxpbak1gJzZP8nWOpZgZn/HioCXnpnf4sQciYnPrk+BFrkfNY?=
 =?us-ascii?Q?7JoY1JJukW+w/IZA8FR1eLtCwiPtEp4sh3S3/0eLNRvfPlPyhhK2S23IealC?=
 =?us-ascii?Q?jeaFyY04Gq+haMJwvLM0dho9BjLPR4FQu9aESJSEkKe6w4FXrnOFJi10QWr2?=
 =?us-ascii?Q?IPwC6gafTqBx2j6n6D1YtOHDLh6Fpb6mkPH32wybZBjv7MZiyYGkA7tG88o6?=
 =?us-ascii?Q?4Uoeiu/6tcgSYkBfwzPBQjODY3LyoT1PplZKqgHIPB4+YrngtO2BwPhA6yzk?=
 =?us-ascii?Q?wj2rtqtabXOTzFlvTslw05DiMByVoa3r93lVK9lQ?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 5a3503d3-2af7-48ad-73f0-08daeff2826f
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2023 14:30:07.8781
 (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: /Nqc148gCfrfUoPHdFYAMQLcCs/6dEhD518Uay/vLc6P42uLpOYqfRJHTb1xC3PsHbm1evBJQCkR+h41SgM2nA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB7070
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        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

On 2023-01-06 at 12:28:26 +0100, Dietmar Eggemann wrote:
> On 06/01/2023 09:34, Chen Yu wrote:
> > Hi Dietmar,
> > thanks for reviewing the patch!
> > On 2023-01-05 at 12:33:16 +0100, Dietmar Eggemann wrote:
> >> On 16/12/2022 07:11, Chen Yu wrote:
> >>
> >> [...]
> >>
> >>> @@ -5995,6 +6005,18 @@ enqueue_task_fair(struct rq *rq, struct task_struct *p, int flags)
> >>>  
> >>>  static void set_next_buddy(struct sched_entity *se);
> >>>  
> >>> +static inline void dur_avg_update(struct task_struct *p, bool task_sleep)
> >>> +{
> >>> +	u64 dur;
> >>> +
> >>> +	if (!task_sleep)
> >>> +		return;
> >>> +
> >>> +	dur = p->se.sum_exec_runtime - p->se.prev_sum_exec_runtime_vol;
> >>> +	p->se.prev_sum_exec_runtime_vol = p->se.sum_exec_runtime;
> >>
> >> Shouldn't se->prev_sum_exec_runtime_vol be set in enqueue_task_fair()
> >> and not in dequeue_task_fair()->dur_avg_update()? Otherwise `dur` will
> >> contain sleep time.
> >>
> > After the task p is dequeued, p's sum_exec_runtime will not be increased.
> 
> True.
> 
> > Unless task p is switched in again, p's sum_exec_runtime will continue to
> > increase. So dur should not include the sleep time, because we substract
> 
> Not sure I get this sentence? p's se->sum_exec_runtime will only
> increase if p is current, so running?
>
Yes, it was a typo, should be "will not continue to increase".
> > between the sum_exec_runtime rather than rq->clock_task. Not sure if I understand
> > this correctly?
> 
> No, you're right. We're not dealing with time snapshots but rather with
> sum_exec_runtime snapshots. So the value will not change between dequeue
> and the next enqueue.
> 
> e ... enqueue_task_fair()
> d ... dequeue_task_fair()
> s ... set_next_entity()
> p ... put_prev_entity()
> u ... update_curr_fair()->update_curr()
> 
> p1:
> 
> ---|---||--|--|---|--|--||---
>    d   es  u  p   s  u  pd
> 
>    ^   ^
>    |   |
>   (A) (B)
> 
> Same se->prev_sum_exec_runtime_vol value in (A) and (B).
> 
Yes.
> > My original thought was that, record the average run time of every section:
> > Only consider that task voluntarily relinquishes the CPU.
> > For example, suppose on CPU1, task p1 and p2 run alternatively:
> > 
> >  --------------------> time
> > 
> >  | p1 runs 1ms | p2 preempt p1 | p1 switch in, runs 0.5ms and blocks |
> >                ^               ^                                     ^
> >  |_____________|               |_____________________________________|
> >                                                                      ^
> >                                                                      |
> >                                                                   p1 dequeued
> > 
> > p1's duration in one section is (1 + 0.5)ms. Because if p2 does not
> > preempt p1, p1 can run 1.5ms. This reflects the nature of a task,
> > how long it wishes to run at most.
> > 
> >> Like we do for se->prev_sum_exec_runtime in set_next_entity() but for
> >> one `set_next_entity()-put_prev_entity()` run section.
> >>
> >> AFAICS, you want to measure the exec_runtime sum over all run sections
> >> between enqueue and dequeue.
> > Yes, we tried to record the 'decayed' average exec_runtime for each section.
> > Say, task p runs for a ms , then p is dequeued and blocks for b ms, and then
> > runs for c ms, its average duration is 0.875 * a + 0.125 * c , which is
> > what update_avg() does.
> 
> OK.
> 
I'll add more descriptions in next version to avoid confusing.

thanks,
Chenyu