DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=ALOqbZ8PRoISa4iOKUv3ct/3hZ1NLpDxyKyOqcLXCDRgvFn9DX+V8IJj/+WxxqAit0
         QTdrGeTJ85S/ENRHe+3HiljexwWmrVLRKDbEiNQQ6Ss4++RJvXpgCib0uurFT/sEOEmA
         m9by+X5d2Z16FdjMGdjlhv3laBPK1o0tg+Nf0=
MIME-Version: 1.0
In-Reply-To: <20101110160004.GA9092@gondor.retis>
References: <1288333128.8661.137.camel@Palantir>
	<1288333622.8661.141.camel@Palantir>
	<20101110160004.GA9092@gondor.retis>
Date: Wed, 10 Nov 2010 17:12:56 +0100
Message-ID: <AANLkTing2SPvnHUg4tHtn4rp9XYhq3Wip5nFWNVg16W3@mail.gmail.com>
Subject: Re: [RFC][PATCH 02/22] sched: add extended scheduling interface
From: Dhaval Giani <dhaval.giani@gmail.com>
To: Raistlin <raistlin@linux.it>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@elte.hu>,
        Thomas Gleixner <tglx@linutronix.de>,
        Steven Rostedt <rostedt@goodmis.org>,
        Chris Friesen <cfriesen@nortel.com>, oleg@redhat.com,
        Frederic Weisbecker <fweisbec@gmail.com>,
        Darren Hart <darren@dvhart.com>, Johan Eker <johan.eker@ericsson.com>,
        "p.faure" <p.faure@akatech.ch>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Claudio Scordino <claudio@evidence.eu.com>,
        michael trimarchi <trimarchi@retis.sssup.it>,
        Fabio Checconi <fabio@gandalf.sssup.it>,
        Tommaso Cucinotta <cucinotta@sssup.it>,
        Juri Lelli <juri.lelli@gmail.com>,
        Nicola Manica <nicola.manica@disi.unitn.it>,
        Luca Abeni <luca.abeni@unitn.it>,
        Harald Gustafsson <hgu1972@gmail.com>,
        paulmck <paulmck@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3007
Lines: 63

On Wed, Nov 10, 2010 at 5:00 PM, Dhaval Giani <dhaval@retis.sssup.it> wrote:
>> +/*
>> + * Extended scheduling parameters data structure.
>> + *
>> + * This is needed because the original struct sched_param can not be
>> + * altered without introducing ABI issues with legacy applications
>> + * (e.g., in sched_getparam()).
>> + *
>> + * However, the possibility of specifying more than just a priority for
>> + * the tasks may be useful for a wide variety of application fields, e.g.,
>> + * multimedia, streaming, automation and control, and many others.
>> + *
>> + * This variant (sched_param_ex) is meant at describing a so-called
>> + * sporadic time-constrained task. In such model a task is specified by:
>> + * ?- the activation period or minimum instance inter-arrival time;
>> + * ?- the maximum (or average, depending on the actual scheduling
>> + * ? ?discipline) computation time of all instances, a.k.a. runtime;
>> + * ?- the deadline (relative to the actual activation time) of each
>> + * ? ?instance.
>> + * Very briefly, a periodic (sporadic) task asks for the execution of
>> + * some specific computation --which is typically called an instance--
>> + * (at most) every period. Moreover, each instance typically lasts no more
>> + * than the runtime and must be completed by time instant t equal to
>> + * the instance activation time + the deadline.
>> + *
>> + * This is reflected by the actual fields of the sched_param_ex structure:
>> + *
>> + * ?@sched_priority ? ? task's priority (might still be useful)
>> + * ?@sched_deadline ? ? representative of the task's deadline
>> + * ?@sched_runtime ? ? ?representative of the task's runtime
>> + * ?@sched_period ? ? ? representative of the task's period
>> + * ?@sched_flags ? ? ? ?for customizing the scheduler behaviour
>> + *
>> + * There are other fields, which may be useful for implementing (in
>> + * user-space) advanced scheduling behaviours, e.g., feedback scheduling:
>> + *
>> + * ?@curr_runtime ? ? ? task's currently available runtime
>> + * ?@used_runtime ? ? ? task's totally used runtime
>> + * ?@curr_deadline ? ? ?task's current absolute deadline
>> + *
>> + * Given this task model, there are a multiplicity of scheduling algorithms
>> + * and policies, that can be used to ensure all the tasks will make their
>> + * timing constraints.
>> + */
>> +struct sched_param_ex {
>> + ? ? int sched_priority;
>> + ? ? struct timespec sched_runtime;
>> + ? ? struct timespec sched_deadline;
>> + ? ? struct timespec sched_period;
>> + ? ? unsigned int sched_flags;
>> +
>> + ? ? struct timespec curr_runtime;
>> + ? ? struct timespec used_runtime;
>> + ? ? struct timespec curr_deadline;

Can we expose soem of these details via schedstats as opposed to a syscall?

Dhaval
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/