From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752065AbdC0HRt (ORCPT ); Mon, 27 Mar 2017 03:17:49 -0400 Received: from foss.arm.com ([217.140.101.70]:57052 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751466AbdC0HRk (ORCPT ); Mon, 27 Mar 2017 03:17:40 -0400 Date: Mon, 27 Mar 2017 08:17:45 +0100 From: Juri Lelli To: luca abeni Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , Claudio Scordino , Steven Rostedt , Tommaso Cucinotta , Daniel Bristot de Oliveira , Joel Fernandes , Mathieu Poirier Subject: Re: [RFC v5 2/9] sched/deadline: improve the tracking of active utilization Message-ID: <20170327071745.GA10289@e106622-lin> References: <1490327582-4376-1-git-send-email-luca.abeni@santannapisa.it> <1490327582-4376-3-git-send-email-luca.abeni@santannapisa.it> <20170324132041.6fxayfe3id4af3n5@hirez.programming.kicks-ass.net> <20170324224715.4098dbfb@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170324224715.4098dbfb@nowhere> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24/03/17 22:47, Luca Abeni wrote: > Hi Peter, > > On Fri, 24 Mar 2017 14:20:41 +0100 > Peter Zijlstra wrote: > > > On Fri, Mar 24, 2017 at 04:52:55AM +0100, luca abeni wrote: > > [...] > > > > In general I feel it would be nice to have a state diagram included > > somewhere near these two functions. It would be nice to not have to > > dig out the PDF every time. > > Ok... Since I am not good at ascii art, would it be ok to add a textual > description? If yes, I'll add a comment like: > " > The utilization of a task is added to the runqueue's active utilization > when the task becomes active (is enqueued in the runqueue), and is Is enqueued for the first time on a new period, maybe? It seems to be contradictory w.r.t. what below (if wakeup before 0 lag time) otherwise. > removed when the task becomes inactive. A task does not become > immediately inactive when it blocks, but becomes inactive at the so > called "0 lag time"; so, we setup the "inactive timer" to fire at the > "0 lag time". When the "inactive timer" fires, the task utilization is > removed from the runqueue's active utilization. If the task wakes up > again on the same runqueue before the "0 lag time", the active > utilization must not be changed and the "inactive timer" must be > cancelled. If the task wakes up again on a different runqueue before > the "0 lag time", then the task's utilization must be removed from the > previous runqueue's active utilization and must be added to the new > runqueue's active utilization. > In order to avoid races between a task waking up on a runqueue while the > "inactive timer" is running on a different CPU, the "dl_non_contending" > flag is used to indicate that a task is not on a runqueue but is active > (so, the flag is set when the task blocks and is cleared when the > "inactive timer" fires or when the task wakes up). > " > (if this is ok, where can I add this comment?) > Thanks for this Luca. Not sure it adds much to your text above, but we might want to consider adding something like below? --->8--- 1st enqueue +------------------+ | | +---------------->+ ACTIVEcontending | | | | | +----+------+------+ | | ^ | | | +--------+-------+ | | | | dequeue | | wakeup before | INACTIVE | | | 0 lag time | | | | +--------+-------+ | | ^ | | | V | | +----+------+------+ | | | +-----------------+ ACTIVEnonCONTEND | | | 0 lag time +------------------+ elapsed --->8--- Thanks, - Juri