Assuming the sched_rr_timeslice is 100ms, there are several tasks with the
same priority t1, t2, t3, ..., and t1 sleeps every 80ms, the scheduling
timing may be:
t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
80, 100, 100, ..., 20, 100, 100, ..., 60, 100, 100, ..., 40, 100, 100
After applying this patch, the scheduling timing may be:
t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100
Signed-off-by: zhaoxiu.zeng <[email protected]>
---
kernel/sched/rt.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index b48baaba2fc2..51798fefcb36 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1491,9 +1491,13 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int flags)
{
struct sched_rt_entity *rt_se = &p->rt;
- if (flags & ENQUEUE_WAKEUP)
+ if (flags & ENQUEUE_WAKEUP) {
rt_se->timeout = 0;
+ if (p->policy == SCHED_RR)
+ p->rt.time_slice = sched_rr_timeslice;
+ }
+
check_schedstat_required();
update_stats_wait_start_rt(rt_rq_of_se(rt_se), rt_se);
@@ -1544,7 +1548,12 @@ static void requeue_task_rt(struct rq *rq, struct task_struct *p, int head)
static void yield_task_rt(struct rq *rq)
{
- requeue_task_rt(rq, rq->curr, 0);
+ struct task_struct *p = rq->curr;
+
+ if (p->policy == SCHED_RR)
+ p->rt.time_slice = sched_rr_timeslice;
+
+ requeue_task_rt(rq, p, 0);
}
#ifdef CONFIG_SMP
--
2.32.0
On Wed, Dec 22, 2021 at 05:15:26PM +0800, zhaoxiu.zeng wrote:
> Assuming the sched_rr_timeslice is 100ms, there are several tasks with the
> same priority t1, t2, t3, ..., and t1 sleeps every 80ms, the scheduling
> timing may be:
> t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
> 80, 100, 100, ..., 20, 100, 100, ..., 60, 100, 100, ..., 40, 100, 100
>
> After applying this patch, the scheduling timing may be:
> t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
> 80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100
>
Is this what POSIX mandates or why are you sending this to me ?
Hi "zhaoxiu.zeng",
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on tip/sched/core]
[also build test WARNING on v5.16-rc6 next-20211222]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/zhaoxiu-zeng/schedule-SCHED_RR-Give-a-fresh-time-slice-to-the-task-after-after-it-suspends-or-relinquishes/20211222-171838
base: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 82762d2af31a60081162890983a83499c9c7dd74
config: i386-randconfig-s001-20211222 (https://download.01.org/0day-ci/archive/20211223/[email protected]/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/7e5fd85c65d2efc13de4adaa5ebc522894f3d60c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review zhaoxiu-zeng/schedule-SCHED_RR-Give-a-fresh-time-slice-to-the-task-after-after-it-suspends-or-relinquishes/20211222-171838
git checkout 7e5fd85c65d2efc13de4adaa5ebc522894f3d60c
# save the config file to linux build tree
mkdir build_dir
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=i386 SHELL=/bin/bash kernel/sched/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
sparse warnings: (new ones prefixed by >>)
kernel/sched/rt.c:924:70: sparse: sparse: incompatible types in comparison expression (different address spaces):
kernel/sched/rt.c:924:70: sparse: struct task_struct [noderef] __rcu *
kernel/sched/rt.c:924:70: sparse: struct task_struct *
kernel/sched/rt.c:1010:38: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *curr @@ got struct task_struct [noderef] __rcu *curr @@
kernel/sched/rt.c:1010:38: sparse: expected struct task_struct *curr
kernel/sched/rt.c:1010:38: sparse: got struct task_struct [noderef] __rcu *curr
>> kernel/sched/rt.c:1560:35: sparse: sparse: incorrect type in initializer (different address spaces) @@ expected struct task_struct *p @@ got struct task_struct [noderef] __rcu *curr @@
kernel/sched/rt.c:1560:35: sparse: expected struct task_struct *p
kernel/sched/rt.c:1560:35: sparse: got struct task_struct [noderef] __rcu *curr
kernel/sched/rt.c: note: in included file:
kernel/sched/sched.h:2032:25: sparse: sparse: incompatible types in comparison expression (different address spaces):
kernel/sched/sched.h:2032:25: sparse: struct task_struct [noderef] __rcu *
kernel/sched/sched.h:2032:25: sparse: struct task_struct *
kernel/sched/sched.h:2032:25: sparse: sparse: incompatible types in comparison expression (different address spaces):
kernel/sched/sched.h:2032:25: sparse: struct task_struct [noderef] __rcu *
kernel/sched/sched.h:2032:25: sparse: struct task_struct *
kernel/sched/sched.h:2032:25: sparse: sparse: incompatible types in comparison expression (different address spaces):
kernel/sched/sched.h:2032:25: sparse: struct task_struct [noderef] __rcu *
kernel/sched/sched.h:2032:25: sparse: struct task_struct *
vim +1560 kernel/sched/rt.c
1557
1558 static void yield_task_rt(struct rq *rq)
1559 {
> 1560 struct task_struct *p = rq->curr;
1561
1562 if (p->policy == SCHED_RR)
1563 p->rt.time_slice = sched_rr_timeslice;
1564
1565 requeue_task_rt(rq, p, 0);
1566 }
1567
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
Peter Zijlstra <[email protected]> 于2021年12月22日周三 18:41写道：
>
> On Wed, Dec 22, 2021 at 05:15:26PM +0800, zhaoxiu.zeng wrote:
> > Assuming the sched_rr_timeslice is 100ms, there are several tasks with the
> > same priority t1, t2, t3, ..., and t1 sleeps every 80ms, the scheduling
> > timing may be:
> > t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
> > 80, 100, 100, ..., 20, 100, 100, ..., 60, 100, 100, ..., 40, 100, 100
> >
> > After applying this patch, the scheduling timing may be:
> > t1 t2 t3 t1 t2 t3 t1 t2 t3 t1 t2 t3
> > 80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100, ..., 80, 100, 100
> >
>
> Is this what POSIX mandates or why are you sending this to me ?
Thanks for your reply!
I don't see a definition of this in POSIX.
Give a fresh time-slice may decreases context switches, and be more
fairly to the tasks which suspended then resumed.