Date: Tue, 5 Apr 2016 21:32:36 +0200
From: luca abeni <luca.abeni@unitn.it>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
        Juri Lelli <juri.lelli@arm.com>
Subject: Re: [RFC v2 3/7] Improve the tracking of active utilisation
Message-ID: <20160405213236.6ea216e1@utopia>
In-Reply-To: <20160405212424.09edc438@utopia>
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-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1572
Lines: 40

On Tue, 5 Apr 2016 21:24:24 +0200
luca abeni <luca.abeni@unitn.it> wrote:

> On Tue, 5 Apr 2016 20:02:52 +0200
> Peter Zijlstra <peterz@infradead.org> 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.
Double thinking about this: isn't p->pi_lock saving us here?
I mean:
	- try_to_wake_up() takes p->pi_lock before doing anything else
	- so, select_task_rq() is invoked with p->pi_lock locked
	- but inactive_task_timer() does "rq = task_rq_lock(p, &flags)", and
	  task_rq_lock() tries to take p->pi_lock
	- so, we should be safe, no?

Maybe this is why I never managed to trigger this race... :)


			Thanks,
				Luca