Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934300AbcJYJdJ (ORCPT ); Tue, 25 Oct 2016 05:33:09 -0400 Received: from foss.arm.com ([217.140.101.70]:42750 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756133AbcJYJdH (ORCPT ); Tue, 25 Oct 2016 05:33:07 -0400 Date: Tue, 25 Oct 2016 10:33:21 +0100 From: Juri Lelli To: Peter Zijlstra Cc: Tommaso Cucinotta , Luca Abeni , Juri Lelli , linux-kernel@vger.kernel.org, Daniel Bistrot de Oliveira , Ingo Molnar Subject: Re: [RFC PATCH] sched/deadline: show leftover runtime and abs deadline in /proc/-/sched Message-ID: <20161025093321.GS21757@e106622-lin> References: <1477348374-8248-1-git-send-email-tommaso.cucinotta@sssup.it> <20161025092519.GV3102@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161025092519.GV3102@twins.programming.kicks-ass.net> 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 Content-Length: 1356 Lines: 30 On 25/10/16 11:25, Peter Zijlstra wrote: > On Tue, Oct 25, 2016 at 12:32:53AM +0200, Tommaso Cucinotta wrote: > > Hi all, > > > > this is a tiny patch providing readings of the current (leftover) > > runtime and absolute deadline in /proc/*/sched. Mostly useful for > > debugging, I heard others playing with SCHED_DEADLINE had some need > > for similar patches as well. > > > > In addition to debugging, reading the leftover runtime is generally > > useful for adaptive/incremental RT logics that need to check whether > > there's enough runtime left for refining the computed result, or just > > use what we've computed so far and block till the next instance. > > Also, knowing what the absolute scheduling deadline is (along with > > what clock it refers to) might be useful for synchronization purposes. > > (albeit, for real production code, I wouldn't like to parse /proc anyway, > > rather I'd prefer to retrieve those params via eg sched_getscheduler()?) > > So for programmatic use, this interface is not recommended. For > debugging this is fine. > > Not sure what form the programmatic interface should take, we have > precedence in sys_sched_rr_get_interval() for a syscall (we could even > abuse this one). > > Anybody any ideas? > Maybe extend getattr() to return actual runtime params? (instead of the static ones, or along to them)