From: luca abeni <luca.abeni@unitn.it>
To: Tommaso Cucinotta <tommaso.cucinotta@sssup.it>
Cc: Juri Lelli <juri.lelli@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org, linux-dl@retis.sssup.it
Subject: Re: [PATCH] sched/deadline: document behavior of sched_yield()
Date: Fri, 9 Sep 2016 12:00:41 +0200 [thread overview]
Message-ID: <20160909120041.2988e93a@utopia> (raw)
In-Reply-To: <1473410650-30918-2-git-send-email-tommaso.cucinotta@sssup.it>
Hi Tommaso,
On Fri, 9 Sep 2016 10:44:10 +0200
Tommaso Cucinotta <tommaso.cucinotta@sssup.it> wrote:
[...]
> +4.4 Behavior of sched_yield()
> +-----------------------------
> +
> + When a SCHED_DEADLINE task calls sched_yield(), it gives up its
> + remaining runtime and is suspended till the next reservation period,
Maybe I am nitpicking, but I suspect "until" would be more appropriate
than "till" :)
More seriously: the concept of "reservation period" has not been
defined in the document until now... So, I suspect this sentence should
be rephrased using the concepts and terminology defined in the
document...
Maybe instead of saying that the task is suspended you can say that
since the remaining runtime goes to 0 the task is immediately throttled,
and will be able to execute again only after the time is equal to the
scheduling deadline (as explained in "2. Scheduling algorithm").
Except for this, the patch looks good to me, thanks for documenting
yield()!
Thanks,
Luca
> + when its runtime will be replenished. This allows the task to
> + wake-up exactly at the beginning of the next period. Also, this may
> + be useful in the future with bandwidth reclaiming mechanisms, where
> + sched_yield() will make the leftoever runtime available for
> + reclamation by other SCHED_DEADLINE tasks.
> +
> +
> 5. Tasks CPU affinity
> =====================
>
next prev parent reply other threads:[~2016-09-09 10:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-08 20:09 [PATCH] sched/deadline: document behavior of sched_yield() Tommaso Cucinotta
2016-09-09 7:40 ` Juri Lelli
2016-09-09 8:44 ` Tommaso Cucinotta
2016-09-09 8:44 ` Tommaso Cucinotta
2016-09-09 10:00 ` luca abeni [this message]
2016-09-09 12:17 ` Daniel Bristot de Oliveira
2016-09-09 12:24 ` luca abeni
2016-09-09 12:31 ` Daniel Bristot de Oliveira
2016-09-09 12:38 ` luca abeni
2016-09-09 13:15 ` Daniel Bristot de Oliveira
2016-09-09 17:45 ` Tommaso Cucinotta
2016-09-09 17:45 ` Tommaso Cucinotta
2016-09-10 12:41 ` [tip:sched/core] sched/deadline: Document " tip-bot for Tommaso Cucinotta
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=20160909120041.2988e93a@utopia \
--to=luca.abeni@unitn.it \
--cc=juri.lelli@gmail.com \
--cc=linux-dl@retis.sssup.it \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tommaso.cucinotta@sssup.it \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox