Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759859AbcDETbK (ORCPT ); Tue, 5 Apr 2016 15:31:10 -0400 Received: from casper.infradead.org ([85.118.1.10]:45326 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759798AbcDETbJ (ORCPT ); Tue, 5 Apr 2016 15:31:09 -0400 Date: Tue, 5 Apr 2016 21:31:04 +0200 From: Peter Zijlstra To: luca abeni Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Juri Lelli Subject: Re: [RFC v2 3/7] Improve the tracking of active utilisation Message-ID: <20160405193104.GS3408@twins.programming.kicks-ass.net> References: <1459523553-29089-1-git-send-email-luca.abeni@unitn.it> <1459523553-29089-4-git-send-email-luca.abeni@unitn.it> <20160405150036.GA3430@twins.programming.kicks-ass.net> <20160405195657.586e8c97@utopia> <20160405180252.GP3408@twins.programming.kicks-ass.net> <20160405212424.09edc438@utopia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160405212424.09edc438@utopia> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1467 Lines: 33 On Tue, Apr 05, 2016 at 09:24:24PM +0200, luca abeni wrote: > On Tue, 5 Apr 2016 20:02:52 +0200 > Peter Zijlstra wrote: > > > On Tue, Apr 05, 2016 at 07:56:57PM +0200, luca abeni wrote: > > > > > > > + migrate_active = hrtimer_active(&p->dl.inactive_timer); > > > > > + if (migrate_active) > > > > > + sub_running_bw(&p->dl, &rq->dl); > > > > > + raw_spin_unlock(&rq->lock); > > > > > > > > At this point task_rq() is still the above rq, so if the inactive timer > > > > hits here it will lock this rq and subtract the running bw here _again_, > > > > right? > > > I think it will see the task state as TASK_RUNNING, so it will do nothing. > > > Or it will cancelled later when the task is enqueued... I'll double check this. > > > > Right, so this is select_task_rq_dl(), we run this in wakeups, before > > TASK_RUNNING. > > Sigh... I knew I was missing something here... :( > So, I think the solution here is to use double_lock_balance() (or something > like that) to take both the rq locks so that the inactive timer handler cannot > run between sub_running_bw() and add_running_bw()... I'll try this. I'm not sure that'll fix it, because after you unlock both again, we can hit after, and there task_rq() will still be the first rq, not the second. So we again subtract twice from the old rq. Only after __set_task_cpu()'s store to task_thread_info(p)->cpu will the timer hit the new rq. And you cannot hold a lock over that..