[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1295499568.8027.30.camel@marge.simson.net>
Date: Thu, 20 Jan 2011 05:59:28 +0100
From: Mike Galbraith <efault@....de>
To: Yong Zhang <yong.zhang0@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, samu.p.onkalo@...ia.com,
mingo@...e.hu,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
tglx <tglx@...utronix.de>, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: Bug in scheduler when using rt_mutex
On Thu, 2011-01-20 at 12:18 +0800, Yong Zhang wrote:
> On Wed, Jan 19, 2011 at 9:30 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > +static void switched_from_fair(struct rq *rq, struct task_struct *p)
> > +{
> > + struct sched_entity *se = &p->se;
> > + struct cfs_rq *cfs_rq = cfs_rq_of(se);
> > +
> > + /*
> > + * Ensure the task's vruntime is normalized, so that when its
> > + * switched back to the fair class the enqueue_entity(.flags=0) will
> > + * do the right thing.
> > + *
> > + * If it was on_rq, then the dequeue_entity(.flags=0) will already
> > + * have normalized the vruntime, if it was !on_rq, then only when
> > + * the task is sleeping will it still have non-normalized vruntime.
> > + */
> > + if (!se->on_rq && p->state != TASK_RUNNING)
> > + se->vruntime -= cfs_rq->min_vruntime;
>
> Here it's possible that se->vruntime is little than cfs_rq->min_vruntime.
The idea of normalizing is to preserve the offset, so the task can be
enqueued at this same offset, regardless of movement.
For sleepers, we can't usually do this until enqueue time, lest their
sleep time be unaccountable. Here, we have to normalize, so the task's
sleep stops from the vantage point of fair_class upon class exit, and
either resumes where it left off upon re-entry, or the task is enqueued
at it's last offset as usual for runnable tasks.
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists