Re: sched_{set,get}attr() manpage

[Claudio Scordino]

Il 10/04/2014 09:47, Juri Lelli ha scritto:
> Hi all,
>
> On Wed, 9 Apr 2014 17:42:04 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > 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.

Hi Juri, hi Peter,

my two cents:

A syscall to block the task until its next instance is definitely useful.
This way, a periodic task doesn't have to sleep anymore: the kernel 
takes care of unblocking the task at the right moment.
This would be easier (for user-level) and more efficient too.
I don't know if using sched_yield() to get this behavior is a good 
choice or not. You have ways more experience than me :)

Best,

        Claudio

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