Messages in this thread | | | Date | Fri, 27 Jan 2012 20:11:15 +0600 | Subject | Re: [tip:sched/urgent] sched: Fix rq->nr_uninterruptible update race | From | Rakib Mullick <> |
| |
On Fri, Jan 27, 2012 at 2:19 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: > On Fri, 2012-01-27 at 11:20 +0600, Rakib Mullick wrote: >> On Fri, Jan 27, 2012 at 2:25 AM, tip-bot for Peter Zijlstra >> <a.p.zijlstra@chello.nl> wrote:
>> Why would we want to avoid nr_uninterruptible accounting? >> nr_uninterruptible has impact on load calculation, we might not get >> the proper load weight if we don't account it. isn't it? > > Read again ;-) > Wasn't enough! I had to use paper and pen ;-)
> sched_setscheduler() did: > > deactivate_task(); // remove it from the queue > > // change tasks's scheduler paramater > > activate_task(); // queue it in the new place > > it is invariant wrt nr_uninterruptible but does include the > nr_uinterruptile accounting logic. > > Now Kosaki-San noticed that if the task manages to change its ->state at > an inopportune moment (right between the dequeue and enqueue) we'll get > screwy nr_uninterruptible accounting.
I got your point and yes, we'll get screwy nr_uninterruptible accounting if we call {activate,deactivate}_task(). We need to avoid nr_uninterruptible accounting.
Thanks, Rakib -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |