[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070322091824.GD15328@elte.hu>
Date: Thu, 22 Mar 2007 10:18:24 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Mike Galbraith <efault@....de>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>, Willy Tarreau <w@....eu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Xavier Bestel <xavier.bestel@...e.fr>, Mark Lord <lkml@....ca>,
Al Boldi <a1426z@...ab.com>, Con Kolivas <kernel@...ivas.org>,
ck@....kolivas.org, Serge Belyshev <belyshev@...ni.sinp.msu.ru>,
linux-kernel@...r.kernel.org, Nicholas Miell <nmiell@...cast.net>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RSDL v0.31
* Mike Galbraith <efault@....de> wrote:
> Actually, the numbers are an interesting curiosity point, but not as
> interesting as the fact that the deadline mechanism isn't kicking in.
it's not just the scheduling accounting being off, RSDL also seems to be
accessing stale data here:
> >From pull_task():
> /*
> * If this task has already been running on src_rq this priority
> * cycle, make the new runqueue think it has been on its cycle
> */
> if (p->rotation == src_rq->prio_rotation)
> p->rotation = this_rq->prio_rotation;
>
> The intent here is clearly that this task continue on the new cpu as
> if nothing has happened. However, when the task was dequeued,
> p->array was left as it was, points to the last place it was queued.
> Stale data.
it might point to a hot-unplugged CPU's runqueue as well. Which might
work accidentally, but we want this fixed nevertheless.
Ingo
-
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