Message-Id: <20140410094737.844921df5b4a8538fb7ecb28@gmail.com>
Date:	Thu, 10 Apr 2014 09:47:37 +0200
From:	Juri Lelli <juri.lelli@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Henrik Austad <henrik@...tad.us>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	Dario Faggioli <raistlin@...ux.it>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, rostedt@...dmis.org,
	Oleg Nesterov <oleg@...hat.com>, fweisbec@...il.com,
	darren@...art.com, johan.eker@...csson.com, p.faure@...tech.ch,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	claudio@...dence.eu.com, michael@...rulasolutions.com,
	fchecconi@...il.com, tommaso.cucinotta@...up.it,
	nicola.manica@...i.unitn.it, luca.abeni@...tn.it,
	dhaval.giani@...il.com, hgu1972@...il.com,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	insop.song@...il.com, liming.wang@...driver.com, jkacur@...hat.com,
	linux-man@...r.kernel.org
Subject: Re: sched_{set,get}attr() manpage

Hi all,

On Wed, 9 Apr 2014 17:42:04 +0200
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Apr 09, 2014 at 05:19:11PM +0200, Henrik Austad wrote:
> > > 	The following "real-time" policies are also supported, for
> > 
> > why the "'s?
> 
> I borrowed those from SCHED_SETSCHEDULER(2).
> 
> > > 	sched_attr::sched_flags additional flags that can influence
> > > 	scheduling behaviour. Currently as per Linux kernel 3.14:
> > > 
> > > 		SCHED_FLAG_RESET_ON_FORK - resets the scheduling policy
> > > 		to: (struct sched_attr){ .sched_policy = SCHED_OTHER, }
> > > 		on fork().
> > > 
> > > 	is the only supported flag.
> 
> ...
> 
> > > 	The flags argument should be 0.
> > 
> > What about SCHED_FLAG_RESET_ON_FOR?
> 
> Different flags. The one is sched_attr::flags the other is
> sched_setattr(.flags).
> 
> > > 	The other sched_attr fields are filled out as described in
> > > 	sched_setattr().
> > > 
> > >    Scheduling Policies
> > >        The  scheduler  is  the  kernel  component  that decides which runnable
> > >        process will be executed by the CPU next.  Each process has an  associ‐
> > >        ated  scheduling  policy and a static scheduling priority, sched_prior‐
> > >        ity; these are the settings that are modified by  sched_setscheduler().
> > >        The  scheduler  makes it decisions based on knowledge of the scheduling
> > >        policy and static priority of all processes on the system.
> > 
> > Isn't this last sentence redundant/sliglhtly repetitive?
> 
> I borrowed that from SCHED_SETSCHEDULER(2) again.
> 
> > >     SCHED_DEADLINE: Sporadic task model deadline scheduling
> > > 	SCHED_DEADLINE is an implementation of GEDF (Global Earliest
> > > 	Deadline First) with additional CBS (Constant Bandwidth Server).
> > > 	The CBS guarantees that tasks that over-run their specified
> > > 	budget are throttled and do not affect the correct performance
> > > 	of other SCHED_DEADLINE tasks.
> > > 
> > > 	SCHED_DEADLINE tasks will fail FORK(2) with -EAGAIN
> > > 
> > > 	Setting SCHED_DEADLINE can fail with -EINVAL when admission
> > > 	control tests fail.
> > 
> > Perhaps add a note about the deadline-class having higher priority than the 
> > other classes; i.e. if a deadline-task is runnable, it will preempt any 
> > other SCHED_(RR|FIFO) regardless of priority?
> 
> Yes, good point, will do.
> 
> > >    SCHED_FIFO: First In-First Out scheduling
> > >        SCHED_FIFO can only be used with static priorities higher than 0, which
> > >        means that when a SCHED_FIFO processes becomes runnable, it will always
> > >        immediately preempt any currently running SCHED_OTHER, SCHED_BATCH,  or
> > >        SCHED_IDLE  process.  SCHED_FIFO is a simple scheduling algorithm with‐
> > >        out time slicing.  For processes scheduled under the SCHED_FIFO policy,
> > >        the following rules apply:
> > > 
> > >        *  A  SCHED_FIFO  process that has been preempted by another process of
> > >           higher priority will stay at the head of the list for  its  priority
> > >           and  will resume execution as soon as all processes of higher prior‐
> > >           ity are blocked again.
> > > 
> > >        *  When a SCHED_FIFO process becomes runnable, it will be  inserted  at
> > >           the end of the list for its priority.
> > > 
> > >        *  A  call  to  sched_setscheduler()  or sched_setparam(2) will put the
> > >           SCHED_FIFO (or SCHED_RR) process identified by pid at the  start  of
> > >           the  list  if it was runnable.  As a consequence, it may preempt the
> > >           currently  running  process   if   it   has   the   same   priority.
> > >           (POSIX.1-2001 specifies that the process should go to the end of the
> > >           list.)
> > > 
> > >        *  A process calling sched_yield(2) will be put at the end of the list.
> > 
> > How about the recent discussion regarding sched_yield(). Is this correct?
> > 
> > lkml.kernel.org/r/alpine.DEB.2.02.1403312333100.14882@...os.tec.linutronix.de
> > 
> > Is this the correct place to add a note explaining te potentional pitfalls 
> > using sched_yield?
> 
> I'm not sure; there's a SCHED_YIELD(2) manpage to fill with that
> nonsense.
> 
> Also; I realized I have not described the DEADLINE sched_yield()
> behaviour.
> 

So, for SCHED_DEADLINE we currently have this behaviour:

/*
 * Yield task semantic for -deadline tasks is:
 *
 *   get off from the CPU until our next instance, with
 *   a new runtime. This is of little use now, since we
 *   don't have a bandwidth reclaiming mechanism. Anyway,
 *   bandwidth reclaiming is planned for the future, and
 *   yield_task_dl will indicate that some spare budget
 *   is available for other task instances to use it.
 */

But, considering also the discussion above, I'm less sure now that's
what we want. Still, I think we will want some way in the future to be
able to say "I'm finished with my current job, give this remaining
runtime to someone else", like another syscall or something.

Thanks,

- Juri

> > >        No other events will move a process scheduled under the SCHED_FIFO pol‐
> > >        icy in the wait list of runnable processes with equal static priority.
> > > 
> > >        A SCHED_FIFO process runs until either it is blocked by an I/O request,
> > >        it  is  preempted  by  a  higher  priority   process,   or   it   calls
> > >        sched_yield(2).
> > > 
> > >    SCHED_RR: Round Robin scheduling
> > >        SCHED_RR  is  a simple enhancement of SCHED_FIFO.  Everything described
> > >        above for SCHED_FIFO also applies to SCHED_RR, except that each process
> > >        is  only  allowed  to  run  for  a maximum time quantum.  If a SCHED_RR
> > >        process has been running for a time period equal to or longer than  the
> > >        time  quantum,  it will be put at the end of the list for its priority.
> > >        A SCHED_RR process that has been preempted by a higher priority process
> > >        and  subsequently  resumes execution as a running process will complete
> > >        the unexpired portion of its round robin time quantum.  The  length  of
> > >        the time quantum can be retrieved using sched_rr_get_interval(2).
> > 
> > -> Default is 0.1HZ ms
> > 
> > This is a question I get form time to time, having this in the manpage 
> > would be helpful.
> 
> Again, brazenly stolen from SCHED_SETSCHEDULER(2); but yes. Also I'm not
> sure I'd call RR an enhancement of anything much at all ;-)
> 
> > > ERRORS
> > >        EINVAL The scheduling policy is not one  of  the  recognized  policies,
> > >               param is NULL, or param does not make sense for the policy.
> > > 
> > >        EPERM  The calling process does not have appropriate privileges.
> > > 
> > >        ESRCH  The process whose ID is pid could not be found.
> > > 
> > >        E2BIG  The provided storage for struct sched_attr is either too
> > >               big, see sched_setattr(), or too small, see sched_getattr().
> > 
> > Where's the EBUSY? It can throw this from __sched_setscheduler() when it 
> > checks if there's enough bandwidth to run the task.
> 
> Uhhm.. it got lost :-) /me quickly adds.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists