All of lore.kernel.org
 help / color / mirror / Atom feed
From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Chen Yu <yu.c.chen@intel.com>, Chunxin Zang <spring.cxz@gmail.com>
Cc: Honglei Wang <jameshongleiwang@126.com>, <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>, <juri.lelli@redhat.com>,
	<vincent.guittot@linaro.org>, <dietmar.eggemann@arm.com>,
	<rostedt@goodmis.org>, <bsegall@google.com>, <mgorman@suse.de>,
	<bristot@redhat.com>, <vschneid@redhat.com>,
	Mike Galbraith <efault@gmx.de>, <linux-kernel@vger.kernel.org>,
	<yangchen11@lixiang.com>, Jerry Zhou <zhouchunhua@lixiang.com>,
	Chunxin Zang <zangchunxin@lixiang.com>
Subject: Re: [PATCH v2] sched/fair: Reschedule the cfs_rq when current is ineligible
Date: Fri, 14 Jun 2024 08:41:58 +0530	[thread overview]
Message-ID: <9d83771f-3d12-25f0-c3f8-70dd7942e9ce@amd.com> (raw)
In-Reply-To: <ZmryuDqw2fEhHNni@chenyu5-mobl2>

Hello Chenyu,

Sorry, I'm a bit late to the thread but ...

On 6/13/2024 6:53 PM, Chen Yu wrote:
> [..snip..]
>>>
>>> I wonder if we can only take care of the NO_RUN_TO_PARITY case? Something like this,
>>>
>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>>>> index 03be0d1330a6..5e49a15bbdd3 100644
>>>> --- a/kernel/sched/fair.c
>>>> +++ b/kernel/sched/fair.c
>>>> @@ -745,6 +745,21 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
>>>>         return vruntime_eligible(cfs_rq, se->vruntime);
>>>> }
>>>>
>>>> +static bool check_entity_need_preempt(struct cfs_rq *cfs_rq, struct sched_entity *se)
>>>> +{
>>> if (sched_feat(RUN_TO_PARITY) || cfs_rq->nr_running <= 1 ||
>>>      !entity_eligible(cfs_rq, se))
>>> return false;
>>>
>>> return true;
>>>
>>> Thoughts?
>>>
>>
>> This does indeed look better. In that case, do I need to make the changes this way and send
>> out a version 3?
> 
> If you mean the following changes, maybe we can continue the discussion here.
> This is just my 2 cents, not sure what others think of it. Anyway, I can launch some tests.
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8a5b1ae0aa55..c0fdb25f0695 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -744,6 +744,15 @@ int entity_eligible(struct cfs_rq *cfs_rq, struct sched_entity *se)
>   	return vruntime_eligible(cfs_rq, se->vruntime);
>   }
>   
> +static bool check_curr_preempt(struct cfs_rq *cfs_rq, struct sched_entity *curr)
> +{
> +	if (sched_feat(RUN_TO_PARITY) || cfs_rq->nr_running <= 1 ||
> +	    !entity_eligible(cfs_rq, curr))

Shouldn't this return false if "entity_eligible(cfs_rq, curr)" returns 
true since curr is still vruntime eligible on cfs_rq?

Would it better to have check_curr_preempt() as follows:

	if (sched_feat(RUN_TO_PARITY) || cfs_rq->nr_running <= 1)
		return false;

	return entity_eligible(cfs_rq, curr);

which returns false if curr is ineligible and scheduler can go ahead and 
and call schedule to evaluate the next best step?

Please let me know if I'm missing something.

> +		return false;
> +
> +	return true;
> +}
> +
>   static u64 __update_min_vruntime(struct cfs_rq *cfs_rq, u64 vruntime)
>   {
>   	u64 min_vruntime = cfs_rq->min_vruntime;
> [..snip..]

-- 
Thanks and Regards,
Prateek

  parent reply	other threads:[~2024-06-14  3:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-29 14:18 [PATCH v2] sched/fair: Reschedule the cfs_rq when current is ineligible Chunxin Zang
2024-06-04  7:28 ` kernel test robot
2024-06-07  5:07 ` Chen Yu
2024-06-12 10:39   ` Chunxin Zang
2024-06-13 11:54     ` Chen Yu
2024-06-13 12:02       ` Chunxin Zang
2024-06-13 13:23         ` Chen Yu
2024-06-13 13:46           ` Chunxin Zang
2024-06-14  3:11           ` K Prateek Nayak [this message]
2024-06-14  3:16             ` K Prateek Nayak
2024-06-14  4:14               ` Chen Yu

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=9d83771f-3d12-25f0-c3f8-70dd7942e9ce@amd.com \
    --to=kprateek.nayak@amd.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=efault@gmx.de \
    --cc=jameshongleiwang@126.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=spring.cxz@gmail.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=yangchen11@lixiang.com \
    --cc=yu.c.chen@intel.com \
    --cc=zangchunxin@lixiang.com \
    --cc=zhouchunhua@lixiang.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.