All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Juri Lelli <juri.lelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
	Dario Faggioli <raistlin-k2GhghHVRtY@public.gmane.org>,
	lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [SCHED_DEADLINE man pages 2/2] sched(7) SCHED_DEADLINE
Date: Tue, 13 May 2014 19:54:42 +0200	[thread overview]
Message-ID: <53725C62.1060809@gmail.com> (raw)
In-Reply-To: <20140513175210.49eed2e34ac06a3c109ce963-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hello Juri,

On 05/13/2014 05:52 PM, Juri Lelli wrote:
> Hello,
> 
> On Tue, 13 May 2014 17:00:57 +0200
> "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> Hello Peter et al.
>>
>> Here is the section of the sched(7) page that describes SCHED_DEADLINE,
>> as rendered text, with the (entire) raw page source attached. Please 
>> carefully review.
>>
>> Cheers,
>>
>> Michael

[...]

>>        The following diagram clarifies these terms:
>>
>>            arrival/wakeup                   absolute deadline
>>                 |    start time                   |
>>                 |        |                        |
>>                 v        v                        v
>>            -----x--------xooooooooooooooooo-------x--------x---
>>                          |<- comp. time ->|
>>                 |<------- relative deadline ----->|
>>                 |<-------------- period ------------------>|
>>
>>        When  setting  a  SCHED_DEADLINE  policy  for  a thread using
>>        sched_setattr(2), one can specify three parameters:  Runtime,
>>        Deadline,  and  Period.   These parameters do not necessarily
>>        correspond to the aforementioned terms: usual practice is  to
>>        set  Runtime to something bigger than the average computation
>>        time (or worst-case execution time for hard real-time tasks),
>>        Deadline  to  the relative deadline, and Period to the period
>>        of the task.  Thus, for SCHED_DEADLINE scheduling, we have:
>>
>>            arrival/wakeup                   absolute deadline
>>                 |    start time                   |
>>                 |        |                        |
>>                 v        v                        v
>>            -----x--------xooooooooooooooooo-------x--------x---
>>                          |<-- Runtime --->|
> 
>                            |<-- Runtime   --->|
> 
> I originally drew this slightly bigger than comp. time above because we
> usually don't want tasks to be throttled in the average case. It's just
> a rule of thumb.

Ahh -- yes, I see now that I messed this up when I tweaked the
ASCII art. Thanks for catching that. Fixed now.

>>                 |<----------- Deadline ---------->|
>>                 |<-------------- Period ------------------>|
>>
>>        The three deadline-scheduling parameters  correspond  to  the
>>        sched_runtime, sched_deadline, and sched_period fields of the
>>        sched_attr structure;  see  sched_setattr(2).   These  fields
>>        express  value  in nanoseconds.  If sched_period is specified
>>        as 0, then it is made the same as sched_deadline.
>>
>>        The kernel requires that:
>>
>>            sched_runtime <= sched_deadline <= sched_period
>>
>>        In addition, under the current  implementation,  all  of  the
>>        parameter  values  must be at least 1024 (i.e., just over one
>>        microsecond, which is the resolution of the  implementation).
> 
> And below 2^63, as per the last bug fix we discussed.

Fixed.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
To: Juri Lelli <juri.lelli@gmail.com>
Cc: mtk.manpages@gmail.com, Peter Zijlstra <peterz@infradead.org>,
	Dario Faggioli <raistlin@linux.it>,
	lkml <linux-kernel@vger.kernel.org>,
	"linux-man@vger.kernel.org" <linux-man@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [SCHED_DEADLINE man pages 2/2] sched(7) SCHED_DEADLINE
Date: Tue, 13 May 2014 19:54:42 +0200	[thread overview]
Message-ID: <53725C62.1060809@gmail.com> (raw)
In-Reply-To: <20140513175210.49eed2e34ac06a3c109ce963@gmail.com>

Hello Juri,

On 05/13/2014 05:52 PM, Juri Lelli wrote:
> Hello,
> 
> On Tue, 13 May 2014 17:00:57 +0200
> "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> wrote:
> 
>> Hello Peter et al.
>>
>> Here is the section of the sched(7) page that describes SCHED_DEADLINE,
>> as rendered text, with the (entire) raw page source attached. Please 
>> carefully review.
>>
>> Cheers,
>>
>> Michael

[...]

>>        The following diagram clarifies these terms:
>>
>>            arrival/wakeup                   absolute deadline
>>                 |    start time                   |
>>                 |        |                        |
>>                 v        v                        v
>>            -----x--------xooooooooooooooooo-------x--------x---
>>                          |<- comp. time ->|
>>                 |<------- relative deadline ----->|
>>                 |<-------------- period ------------------>|
>>
>>        When  setting  a  SCHED_DEADLINE  policy  for  a thread using
>>        sched_setattr(2), one can specify three parameters:  Runtime,
>>        Deadline,  and  Period.   These parameters do not necessarily
>>        correspond to the aforementioned terms: usual practice is  to
>>        set  Runtime to something bigger than the average computation
>>        time (or worst-case execution time for hard real-time tasks),
>>        Deadline  to  the relative deadline, and Period to the period
>>        of the task.  Thus, for SCHED_DEADLINE scheduling, we have:
>>
>>            arrival/wakeup                   absolute deadline
>>                 |    start time                   |
>>                 |        |                        |
>>                 v        v                        v
>>            -----x--------xooooooooooooooooo-------x--------x---
>>                          |<-- Runtime --->|
> 
>                            |<-- Runtime   --->|
> 
> I originally drew this slightly bigger than comp. time above because we
> usually don't want tasks to be throttled in the average case. It's just
> a rule of thumb.

Ahh -- yes, I see now that I messed this up when I tweaked the
ASCII art. Thanks for catching that. Fixed now.

>>                 |<----------- Deadline ---------->|
>>                 |<-------------- Period ------------------>|
>>
>>        The three deadline-scheduling parameters  correspond  to  the
>>        sched_runtime, sched_deadline, and sched_period fields of the
>>        sched_attr structure;  see  sched_setattr(2).   These  fields
>>        express  value  in nanoseconds.  If sched_period is specified
>>        as 0, then it is made the same as sched_deadline.
>>
>>        The kernel requires that:
>>
>>            sched_runtime <= sched_deadline <= sched_period
>>
>>        In addition, under the current  implementation,  all  of  the
>>        parameter  values  must be at least 1024 (i.e., just over one
>>        microsecond, which is the resolution of the  implementation).
> 
> And below 2^63, as per the last bug fix we discussed.

Fixed.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

  parent reply	other threads:[~2014-05-13 17:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-13 14:54 [SCHED_DEADLINE man pages 0/2] Summary Michael Kerrisk (man-pages)
2014-05-13 14:54 ` Michael Kerrisk (man-pages)
2014-05-13 14:57 ` [SCHED_DEADLINE man pages 1/2] sched_setattr.2 Michael Kerrisk (man-pages)
2014-05-13 15:00 ` [SCHED_DEADLINE man pages 2/2] sched(7) SCHED_DEADLINE Michael Kerrisk (man-pages)
     [not found]   ` <537233A9.6040102-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-13 15:52     ` Juri Lelli
2014-05-13 15:52       ` Juri Lelli
     [not found]       ` <20140513175210.49eed2e34ac06a3c109ce963-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-13 17:54         ` Michael Kerrisk (man-pages) [this message]
2014-05-13 17:54           ` Michael Kerrisk (man-pages)
     [not found] ` <53723235.40101-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-13 15:27   ` [SCHED_DEADLINE man pages 0/2] Summary Peter Zijlstra
2014-05-13 15:27     ` Peter Zijlstra
2014-05-13 17:56     ` Michael Kerrisk (man-pages)
2014-05-13 15:54   ` Juri Lelli
2014-05-13 15:54     ` Juri Lelli
     [not found]     ` <20140513175416.765abe5b536257ab72d827bc-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-05-13 18:00       ` Michael Kerrisk (man-pages)
2014-05-13 18:00         ` Michael Kerrisk (man-pages)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53725C62.1060809@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=juri.lelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org \
    --cc=raistlin-k2GhghHVRtY@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.