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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19673C4361B for ; Mon, 14 Dec 2020 18:47:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CA90F22573 for ; Mon, 14 Dec 2020 18:47:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2439998AbgLNSrr (ORCPT ); Mon, 14 Dec 2020 13:47:47 -0500 Received: from foss.arm.com ([217.140.110.172]:51770 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2440537AbgLNSrM (ORCPT ); Mon, 14 Dec 2020 13:47:12 -0500 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 40A8B1FB; Mon, 14 Dec 2020 10:46:21 -0800 (PST) Received: from [192.168.178.2] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DD3C23F66E; Mon, 14 Dec 2020 10:46:17 -0800 (PST) Subject: Re: [PATCH] fair/util_est: Separate util_est_dequeue() for cfs_rq_util_change To: Ryan Y Cc: patrick.bellasi@arm.com, Vincent Guittot , peterz@infradead.org, mingo@redhat.com, juri.lelli@redhat.com, rostedt@goodmis.org, Benjamin Segall , mgorman@suse.de, bristot@redhat.com, linux-kernel@vger.kernel.org, Xuewen Yan , Ryan Y , zhang.lyra@gmail.com, Ke.Wang@unisoc.com References: <1607510656-22990-1-git-send-email-xuewen.yan@unisoc.com> <2edefcc7-ccea-5665-728e-5b86ac413629@arm.com> From: Dietmar Eggemann Message-ID: Date: Mon, 14 Dec 2020 19:46:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/12/2020 13:03, Ryan Y wrote: > Hi Dietmar, > > Yes! That's exactly what I meant. > >> The issue is that sugov_update_[shared\|single] -> sugov_get_util() -> >> cpu_util_cfs() operates on an old cfs_rq->avg.util_est.enqueued value? > > well, because of this, when the p dequeued, _task_util_est(p) should be > subtracted before cfs_rq_util_change(). > however, the original util_est_dequeue() dequeue the util_est and update > the > p->se.avg.util_est together. > so I separate the original util_est_dequeue() to deal with the issue. OK, I see. I ran a testcase '50% periodic task 'task0-0' (8ms/16ms)' with PELT + proprietary trace events within dequeue_task_fair() call: task0-0-1710 [002] 218.215535: sched_pelt_se: cpu=2 path=(null) comm=task0-0 pid=1710 load=596 runnable=597 util=597 update_time=218123022336 task0-0-1710 [002] 218.215536: sched_pelt_cfs: cpu=2 path=/ load=597 runnable=597 util=597 update_time=218123022336 task0-0-1710 [002] 218.215538: bprint: sugov_get_util: CPU2 rq->cfs.avg.util_avg=597 rq->cfs.avg.util_est.enqueued=601 task0-0-1710 [002] 218.215540: sched_util_est_cfs: cpu=2 path=/ enqueued=0 ewma=0 util=597 task0-0-1710 [002] 218.215542: bprint: dequeue_task_fair: CPU2 [task0-0 1710] rq->cfs.avg.util_avg=[576->597] rq->cfs.avg.util_est.enqueued=[601->0] It's true that 'sugov_get_util() -> cpu_util_cfs()' can use rq->cfs.avg.util_est.enqueued before _task_util_est(p) is subtracted from it. But isn't rq->cfs.avg.util_est.enqueued (in this case 601) always close to rq->cfs.avg.util_avg (597) since the task was just running? The cfs_rq utilization contains a blocked (sleeping) task. If I would run with your patch cpu_util_cfs() would chose between 597 and 0 whereas without it does between 597 and 601. Do you have a specific use case in mind? Or even test results showing a benefit of your patch? > Dietmar Eggemann 于2020年12月11日周五 下午7:30写道： > >> Hi Yan, >> >> On 09/12/2020 11:44, Xuewen Yan wrote: >>> when a task dequeued, it will update it's util, and cfs_rq_util_change >>> would check rq's util, if the cfs_rq->avg.util_est.enqueued is bigger >>> than cfs_rq->avg.util_avg, but because the cfs_rq->avg.util_est.enqueued >>> didn't be decreased, this would cause bigger cfs_rq_util by mistake, >>> as a result, cfs_rq_util_change may change freq unreasonablely. >>> >>> separate the util_est_dequeue() into util_est_dequeue() and >>> util_est_update(), and dequeue the _task_util_est(p) before update util. >> >> The issue is that sugov_update_[shared\|single] -> sugov_get_util() -> >> cpu_util_cfs() operates on an old cfs_rq->avg.util_est.enqueued value? >> >> cpu_util_cfs() >> >> if (sched_feat(UTIL_EST)) >> util = max_t(util, READ_ONCE(rq->cfs.avg.util_est.enqueued)) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> dequeue_task_fair() (w/ your patch, moving (1) before (2)) >> >> /* (1) update cfs_rq->avg.util_est.enqueued */ >> util_est_dequeue() >> >> /* (2) potential p->se.avg.util_avg update */ >> /* 2 for loops */ >> for_each_sched_entity() >> >> /* this can only lead to a freq change for a root cfs_rq */ >> (dequeue_entity() ->) update_load_avg() -> cfs_rq_util_change() >> -> cpufreq_update_util() ->...-> sugov_update_[shared\|single] >> >> /* (3) potential update p->se.avg.util_est */ >> util_est_update() >> >> >> We do need (3) after (2) because of: >> >> util_est_update() >> ... >> ue.enqueued = (task_util(p) | UTIL_AVG_UNCHANGED); task_util >> ... ^^^^^^^^^^^^^ >> p->se.avg.util_avg >> >> >> Did I get this right? >> >> [...]