lkml.org 
[lkml]   [2009]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: scheduler oddity [bug?]

* Mike Galbraith <efault@gmx.de> wrote:

> The problem with your particular testcase is that while one
> half has an avg_overlap (what we use as affinity hint for
> synchronous wakeups) which triggers the affinity hint, the
> other half has avg_overlap of zero, what it was born with, so
> despite significant execution overlap, the scheduler treats
> them as if they were truly synchronous tasks.

hm, why does it stay on zero?

> static void dequeue_task(struct rq *rq, struct task_struct *p, int sleep)
> {
> + u64 limit = sysctl_sched_migration_cost;
> + u64 runtime = p->se.sum_exec_runtime - p->se.prev_sum_exec_runtime;
> +
> if (sleep && p->se.last_wakeup) {
> update_avg(&p->se.avg_overlap,
> p->se.sum_exec_runtime - p->se.last_wakeup);
> p->se.last_wakeup = 0;
> - }
> + } else if (p->se.avg_overlap < limit && runtime >= limit)
> + update_avg(&p->se.avg_overlap, runtime);
>
> sched_info_dequeued(p);
> p->sched_class->dequeue_task(rq, p, sleep);

hm, that's weird. We want to limit avg_overlap maintenance to
true sleeps only.

And this patch only makes a difference in the !sleep case -
which shouldnt be that common in this workload.

What am i missing? A trace would be nice of a few millisecs of
runtime of this workload, with a few more trace_printk()'s added
showing how avg_overlap develops.

Maybe it's some task migration artifact? There we do a
dequeue/enqueue with sleep=0.

Ingo


\
 
 \ /
  Last update: 2009-03-08 16:43    [W:0.076 / U:60.744 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site