From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933404AbcKIPZc (ORCPT ); Wed, 9 Nov 2016 10:25:32 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:36280 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932638AbcKIPZa (ORCPT ); Wed, 9 Nov 2016 10:25:30 -0500 Date: Wed, 9 Nov 2016 16:25:21 +0100 From: luca abeni To: Juri Lelli Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Claudio Scordino , Steven Rostedt Subject: Re: [RFC v3 1/6] Track the active utilisation Message-ID: <20161109162521.1e38573a@utopia> In-Reply-To: <20161108200229.GA24076@ARMvm> References: <1477317998-7487-1-git-send-email-luca.abeni@unitn.it> <1477317998-7487-2-git-send-email-luca.abeni@unitn.it> <20161101164451.GA2769@ARMvm> <20161101221014.27eb441a@utopia> <20161108175635.GF16920@e106622-lin> <20161108191730.29c54a98@utopia> <20161108185309.GG16920@e106622-lin> <20161108200956.35b3e7c7@utopia> <20161108200229.GA24076@ARMvm> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 8 Nov 2016 20:02:29 +0000 Juri Lelli wrote: [...] > > > So, it actually matters for next patch, > > > not here. But, maybe we want to do things clean from start? > > You mean, because patch 2/6 adds > > + if (hrtimer_active(&p->dl.inactive_timer)) { > > + raw_spin_lock_irq(&task_rq(p)->lock); > > + sub_running_bw(&p->dl, dl_rq_of_se(&p->dl)); > > + raw_spin_unlock_irq(&task_rq(p)->lock); > > + } > > in task_dead_dl()? I suspect this hunk is actually unneeded (worse, it > > is wrong :). I am trying to remember why it is there, but I cannot find > > any reason... In the next days, I'll run some tests to check if that > > hunk is actually needed. If yes, then I'll modify patch 1/6 as you > > suggest; if it is not needed, I'll remove it from patch 2/6 and I'll > > not do this change to patch 1/6... Is this ok? > > > > I guess yes, if we don't need to differentiate. Ok; so, I ran some tests (and I found some old notes of mine). The modifications to task_dead_dl() mentioned above are not actually needed; I added them as a preparation for a change needed by patch 3... But I now think this was an error; I am reworking this part of the code (removing changes from task_dead_dl() and adding a "p->state == TASK_DEAD" check in the inactive timer handler). I'll post an update for patches 2 and 3 in few days, after I finish some more tests. Luca > Maybe just add a comment as I am saying above? > > Thanks, > > - Juri