lkml.org 
[lkml]   [2014]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sched_{set,get}attr() manpage
Il 10/04/2014 09:47, Juri Lelli ha scritto:
> Hi all,
>
> On Wed, 9 Apr 2014 17:42:04 +0200
> Peter Zijlstra <peterz@infradead.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@ionos.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.

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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2014-04-10 12:21    [W:0.131 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site