[lkml]   [2015]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues
On Wed, Oct 28, 2015 at 6:58 PM, Peter Zijlstra <> wrote:
> On Wed, Oct 28, 2015 at 05:57:10PM -0700, Olav Haugan wrote:
>> On 15-10-25 11:09:24, Peter Zijlstra wrote:
>> > On Sat, Oct 24, 2015 at 11:01:02AM -0700, Olav Haugan wrote:
>> > > Task->on_rq has three states:
>> > > 0 - Task is not on runqueue (rq)
>> > > 1 (TASK_ON_RQ_QUEUED) - Task is on rq
>> > > 2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the process of being
>> > > migrated to another rq
>> > >
>> > > When a task is moving between rqs task->on_rq state should be
>> >
>> > Only when not holding both rq locks..
>> IMHO I think we should keep the state of p->on_rq updated with the correct state
>> all the time unless I am incorrect in what p->on_rq represent. The task
>> is moving between rq's and is on the rq so the state should be
>> TASK_ON_RQ_MIGRATING right? I do realize that the code is currently not
>> broken. However, in the future someone might come along and change
>> set_task_cpu() and the code change might rely on an accurate p->on_rq value. It
>> would be good design to keep this value correct.
> At the same time; we should also provide lean and fast code. Is it
> better to add assertions about required state than to add superfluous
> code for just in case scenarios.

The state is only worth publishing if it's exceptional. I think
Peter's new documentation helps to make this more clear.

The intent of this change may be better captured by pointing out in a
comment somewhere that detach_task() is *also* updating the task_cpu
pointer which then lets us lean on holding that lock to make the state
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> More majordomo info at
> Please read the FAQ at

 \ /
  Last update: 2015-11-02 22:01    [W:0.080 / U:4.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site