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 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.