Mike,
Could you try this patch to see if it solves the latency problem?
tong
Changes:
1. Modified vruntime adjustment logic in set_task_cpu(). See comments in
code. This fixed the negative vruntime problem.
2. This code in update_curr() seems to be wrong:
if (unlikely(!curr))
return sync_vruntime(cfs_rq);
cfs_rq->curr can be NULL even if cfs_rq->nr_running is non-zero (e.g.,
when an RT task is running). We only want to call sync_vruntime when
cfs_rq->nr_running is 0. This fixed the large latency problem (at least in
my tests).
Signed-off-by: Tong Li <[email protected]>
---
diff -uprN linux-2.6-sched-devel-orig/kernel/sched.c linux-2.6-sched-devel/kernel/sched.c
--- linux-2.6-sched-devel-orig/kernel/sched.c 2007-09-20 12:15:41.000000000 -0700
+++ linux-2.6-sched-devel/kernel/sched.c 2007-09-21 19:40:08.000000000 -0700
@@ -1033,9 +1033,20 @@ void set_task_cpu(struct task_struct *p,
if (p->se.block_start)
p->se.block_start -= clock_offset;
#endif
- if (likely(new_rq->cfs.min_vruntime))
- p->se.vruntime -= old_rq->cfs.min_vruntime -
- new_rq->cfs.min_vruntime;
+ /*
+ * Reset p's vruntime if it moves to new_cpu whose min_vruntime is
+ * 100,000,000 (equivalent to 100ms for nice-0 tasks) larger or
+ * smaller than p's vruntime. This improves interactivity when
+ * pinned and unpinned tasks co-exist. For example, pinning a few
+ * tasks to a CPU can cause its min_vruntime much smaller than the
+ * other CPUs. If a task moves to this CPU, its vruntime can be so
+ * large it won't be scheduled until the locally pinned tasks'
+ * vruntimes catch up, causing large delays.
+ */
+ if (unlikely(old_cpu != new_cpu && p->se.vruntime &&
+ (p->se.vruntime > new_rq->cfs.min_vruntime + 100000000 ||
+ p->se.vruntime + 100000000 < new_rq->cfs.min_vruntime)))
+ p->se.vruntime = new_rq->cfs.min_vruntime;
__set_task_cpu(p, new_cpu);
}
@@ -1599,6 +1610,7 @@ static void __sched_fork(struct task_str
p->se.exec_start = 0;
p->se.sum_exec_runtime = 0;
p->se.prev_sum_exec_runtime = 0;
+ p->se.vruntime = 0;
#ifdef CONFIG_SCHEDSTATS
p->se.wait_start = 0;
diff -uprN linux-2.6-sched-devel-orig/kernel/sched_fair.c linux-2.6-sched-devel/kernel/sched_fair.c
--- linux-2.6-sched-devel-orig/kernel/sched_fair.c 2007-09-20 12:15:41.000000000 -0700
+++ linux-2.6-sched-devel/kernel/sched_fair.c 2007-09-21 17:23:09.000000000 -0700
@@ -306,8 +306,10 @@ static void update_curr(struct cfs_rq *c
u64 now = rq_of(cfs_rq)->clock;
unsigned long delta_exec;
- if (unlikely(!curr))
+ if (unlikely(!cfs_rq->nr_running))
return sync_vruntime(cfs_rq);
+ if (unlikely(!curr))
+ return;
/*
* Get the amount of time the current task was running
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
- Re: [git] CFS-devel, group scheduler, fixes
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]