From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues Date: Thu, 29 Oct 2015 02:58:52 +0100 Message-ID: <20151029015852.GF11242@worktop.amr.corp.intel.com> References: <1445709662-17232-1-git-send-email-ohaugan@codeaurora.org> <20151025100924.GP2508@worktop.programming.kicks-ass.net> <20151029005710.GA11285@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from bombadil.infradead.org ([198.137.202.9]:33218 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750775AbbJaS6z (ORCPT ); Sat, 31 Oct 2015 14:58:55 -0400 Content-Disposition: inline In-Reply-To: <20151029005710.GA11285@codeaurora.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Olav Haugan Cc: mingo@redhat.com, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org 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.