From: Chen Yu <yu.c.chen@intel.com>
To: Chunxin Zang <spring.cxz@gmail.com>
Cc: <mingo@redhat.com>, <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>, <linux-kernel@vger.kernel.org>,
<yangchen11@lixiang.com>, <zhouchunhua@lixiang.com>,
<zangchunxin@lixiang.com>, <kprateek.nayak@amd.com>
Subject: Re: [PATCH] sched/fair: Reschedule the cfs_rq when current is ineligible
Date: Fri, 24 May 2024 23:30:12 +0800 [thread overview]
Message-ID: <ZlCyhDspcZQhxlNk@chenyu5-mobl2> (raw)
In-Reply-To: <20240524134011.270861-1-spring.cxz@gmail.com>
On 2024-05-24 at 21:40:11 +0800, Chunxin Zang wrote:
> I found that some tasks have been running for a long enough time and
> have become illegal, but they are still not releasing the CPU. This
> will increase the scheduling delay of other processes. Therefore, I
> tried checking the current process in wakeup_preempt and entity_tick,
> and if it is illegal, reschedule that cfs queue.
>
> The modification can reduce the scheduling delay by about 30% when
> RUN_TO_PARITY is enabled.
> So far, it has been running well in my test environment, and I have
> pasted some test results below.
>
Interesting, besides hackbench, I assume that you have workload in
real production environment that is sensitive to wakeup latency?
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 03be0d1330a6..a0005d240db5 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5523,6 +5523,9 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
> hrtimer_active(&rq_of(cfs_rq)->hrtick_timer))
> return;
> #endif
> +
> + if (!entity_eligible(cfs_rq, curr))
> + resched_curr(rq_of(cfs_rq));
> }
>
entity_tick() -> update_curr() -> update_deadline():
se->vruntime >= se->deadline ? resched_curr()
only current has expired its slice will it be scheduled out.
So here you want to schedule current out if its lag becomes 0.
In lastest sched/eevdf branch, it is controlled by two sched features:
RESPECT_SLICE: Inhibit preemption until the current task has exhausted it's slice.
RUN_TO_PARITY: Relax RESPECT_SLICE and only protect current until 0-lag.
https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=sched/eevdf&id=e04f5454d68590a239092a700e9bbaf84270397c
Maybe something like this can achieve your goal
if (sched_feat(RUN_TOPARITY) && !entity_eligible(cfs_rq, curr))
resched_curr
>
> @@ -8325,6 +8328,9 @@ static void check_preempt_wakeup_fair(struct rq *rq, struct task_struct *p, int
> if (unlikely(p->policy != SCHED_NORMAL) || !sched_feat(WAKEUP_PREEMPTION))
> return;
>
> + if (!entity_eligible(cfs_rq, se))
> + goto preempt;
> +
Not sure if this is applicable, later in this function, pick_eevdf() checks
if the current is eligible, !entity_eligible(cfs_rq, curr), if not, curr will
be evicted. And this change does not consider the cgroup hierarchy.
Besides, the check of current eligiblity can get false negative result,
if the enqueued entity has a positive lag. Prateek proposed to
remove the check of current's eligibility in pick_eevdf():
https://lore.kernel.org/lkml/20240325060226.1540-2-kprateek.nayak@amd.com/
If I understand your requirement correctly, you want to reduce the wakeup
latency. There are some codes under developed by Peter, which could
customized task's wakeup latency via setting its slice:
https://lore.kernel.org/lkml/20240405110010.934104715@infradead.org/
thanks,
Chenyu
next prev parent reply other threads:[~2024-05-24 15:30 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-24 13:40 [PATCH] sched/fair: Reschedule the cfs_rq when current is ineligible Chunxin Zang
2024-05-24 15:30 ` Chen Yu [this message]
2024-05-28 2:42 ` Chunxin Zang
2024-05-28 5:02 ` K Prateek Nayak
2024-05-28 7:18 ` Chunxin Zang
2024-05-28 7:47 ` K Prateek Nayak
2024-06-05 17:19 ` Chen Yu
2024-06-06 1:46 ` Chunxin Zang
2024-06-07 2:38 ` Chen Yu
2024-06-11 13:10 ` Chunxin Zang
2024-06-13 11:45 ` Chen Yu
2024-05-28 6:41 ` Chunxin Zang
2024-05-25 6:41 ` Mike Galbraith
2024-05-25 11:57 ` Chen Yu
2024-05-25 17:22 ` Mike Galbraith
2024-05-27 8:05 ` Peter Zijlstra
2024-05-27 9:53 ` Mike Galbraith
2024-05-25 11:48 ` Honglei Wang
[not found] ` <6AF97701-B8F4-46C6-851E-A8BACE97E8C0@gmail.com>
2024-06-03 2:55 ` Honglei Wang
2024-06-06 12:39 ` Chunxin Zang
2024-06-11 11:39 ` Honglei Wang
2024-05-29 6:06 ` kernel test robot
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=ZlCyhDspcZQhxlNk@chenyu5-mobl2 \
--to=yu.c.chen@intel.com \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=dietmar.eggemann@arm.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox