From: Yiwei Lin <s921975628@gmail.com>
To: Abel Wu <wuyun.abel@bytedance.com>
Cc: Barry Song <21cnbao@gmail.com>,
Benjamin Segall <bsegall@google.com>,
Chen Yu <yu.c.chen@intel.com>,
Daniel Jordan <daniel.m.jordan@oracle.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
Joel Fernandes <joel@joelfernandes.org>,
K Prateek Nayak <kprateek.nayak@amd.com>,
Mike Galbraith <efault@gmx.de>, Qais Yousef <qyousef@layalina.io>,
Tim Chen <tim.c.chen@linux.intel.com>,
Yicong Yang <yangyicong@huawei.com>,
Youssef Esmat <youssefesmat@chromium.org>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Valentin Schneider <valentin.schneider@arm.com>
Subject: Re: [PATCH 1/4] sched/eevdf: Fix vruntime adjustment on reweight
Date: Thu, 16 Nov 2023 14:51:29 +0800 [thread overview]
Message-ID: <446aeb22-55c4-4ef6-81cc-1d1d994d5268@gmail.com> (raw)
In-Reply-To: <19c6accf-1cc0-489d-9c82-e0ddf982b098@bytedance.com>
On 11/16/23 13:07, Abel Wu wrote:
> On 11/16/23 12:48 PM, Abel Wu Wrote:
>> On 11/15/23 11:36 PM, Yiwei Lin Wrote:
>>>
>>>> @@ -3712,8 +3811,17 @@ static void reweight_entity(struct cfs_rq
>>>> *cfs_rq, struct sched_entity *se,
>>>> enqueue_load_avg(cfs_rq, se);
>>>> if (se->on_rq) {
>>>> update_load_add(&cfs_rq->load, se->load.weight);
>>>> - if (cfs_rq->curr != se)
>>>> - avg_vruntime_add(cfs_rq, se);
>>>> + if (!curr) {
>>>> + /*
>>>> + * The entity's vruntime has been adjusted, so let's
>>>> check
>>>> + * whether the rq-wide min_vruntime needs updated too.
>>>> Since
>>>> + * the calculations above require stable min_vruntime
>>>> rather
>>>> + * than up-to-date one, we do the update at the end of
>>>> the
>>>> + * reweight process.
>>>> + */
>>>> + __enqueue_entity(cfs_rq, se);
>>>> + update_min_vruntime(cfs_rq);
>>>> + }
>>>> }
>>>> }
>>> Sorry if I am asking stupid question...... It looks like
>>> reweight_entity() may have chance to change the weight of
>>> cfs_rq->curr entity, but we'll never update_min_vruntime() when
>>> reweighting it. Is there any reason that we can skip the
>>> update_min_vruntime() for this case?
>>
>> No, you are right!
>
> I was intended to update_min_vruntime() if se->on_rq and no matter
> it is curr or not, just as you suggested. But after a second thought
> I wonder if it is necessary to update *NOW*, since we will always
> update_curr() before making any change to cfs_rq. Thoughts?
I lost the fact that we'll update_min_vruntime() every time we
update_curr(). Because of this fact, we can indeed wait until we need
the correct min_vruntime and update_min_vruntime() then. The only
consideration that I came up with is that the sched_debug may not be
able to reflect the accurate min_vruntime in time. But this may not be a
big problem.
Further, I have another advanced thought we can remove the
update_min_vruntime() here in the reweight_entity() directly to save
more time. The reason that I think this is because min_vruntime is not
for normalization of vruntime as before which is required on CFS, so we
will always update_curr() for the latest min_vruntime before using it.
Also, the update_min_vruntime() in dequeue_entity() may also be removed
as the reason, i.e. just do update_min_vruntime() in update_curr() to
simplify. What do you think?
Thanks,
Yiwei Lin
next prev parent reply other threads:[~2023-11-16 6:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 9:05 [PATCH 0/4] sched/eevdf: Optimize reweight and pick Abel Wu
2023-11-07 9:05 ` [PATCH 1/4] sched/eevdf: Fix vruntime adjustment on reweight Abel Wu
2023-11-07 9:52 ` Peter Zijlstra
2023-11-14 21:57 ` [tip: sched/urgent] " tip-bot2 for Abel Wu
2023-11-15 15:36 ` [PATCH 1/4] " Yiwei Lin
2023-11-16 4:48 ` Abel Wu
2023-11-16 4:59 ` Yiwei Lin
2023-11-16 9:01 ` Abel Wu
2023-11-16 5:07 ` Abel Wu
2023-11-16 6:51 ` Yiwei Lin [this message]
2023-11-16 7:11 ` Abel Wu
2024-02-29 9:24 ` Tianchen Ding
2024-02-29 14:25 ` Abel Wu
2024-03-01 6:41 ` Tianchen Ding
2024-03-01 8:30 ` Abel Wu
2024-03-01 10:04 ` Tianchen Ding
2023-11-07 9:05 ` [PATCH 2/4] sched/eevdf: Sort the rbtree by virtual deadline Abel Wu
2023-11-07 11:03 ` Peter Zijlstra
2023-11-07 11:06 ` Abel Wu
2023-11-07 23:26 ` Benjamin Segall
2023-11-08 8:51 ` Abel Wu
2023-11-07 9:05 ` [PATCH 3/4] sched/eevdf: O(1) fastpath for task selection Abel Wu
2023-11-07 10:12 ` Abel Wu
2023-11-07 10:42 ` Peter Zijlstra
2023-11-07 9:05 ` [PATCH 4/4] sched/stats: branch statistics for pick_eevdf Abel Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=446aeb22-55c4-4ef6-81cc-1d1d994d5268@gmail.com \
--to=s921975628@gmail.com \
--cc=21cnbao@gmail.com \
--cc=bsegall@google.com \
--cc=daniel.m.jordan@oracle.com \
--cc=dietmar.eggemann@arm.com \
--cc=efault@gmx.de \
--cc=gautham.shenoy@amd.com \
--cc=joel@joelfernandes.org \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=qyousef@layalina.io \
--cc=tim.c.chen@linux.intel.com \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
--cc=wuyun.abel@bytedance.com \
--cc=yangyicong@huawei.com \
--cc=youssefesmat@chromium.org \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome