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 > > > TASK_ON_RQ_MIGRATING > > > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
