Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753543AbbKBUlK (ORCPT ); Mon, 2 Nov 2015 15:41:10 -0500 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37436 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752708AbbKBUlI (ORCPT ); Mon, 2 Nov 2015 15:41:08 -0500 MIME-Version: 1.0 In-Reply-To: <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> <20151029015852.GF11242@worktop.amr.corp.intel.com> From: Paul Turner Date: Mon, 2 Nov 2015 12:40:36 -0800 Message-ID: Subject: Re: [PATCH] sched: Update task->on_rq when tasks are moving between runqueues To: Peter Zijlstra Cc: Olav Haugan , Ingo Molnar , LKML , linux-arm-msm@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2180 Lines: 44 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 >> > > 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. 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 non-interesting.` > -- > 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/ -- 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/