All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juri Lelli <juri.lelli@arm.com>
To: Michael Riesch <michael@riesch.at>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"juri.lelli@gmail.com" <juri.lelli@gmail.com>
Subject: Re: Question about SCHED_DEADLINE and sched_yield() usage
Date: Wed, 12 Aug 2015 11:52:37 +0100	[thread overview]
Message-ID: <55CB2575.4060201@arm.com> (raw)
In-Reply-To: <55CB0D9E.6020700@riesch.at>

Hi,

On 12/08/15 10:10, Michael Riesch wrote:
> Hi Juri,
> 
> On 08/11/2015 01:55 PM, Juri Lelli wrote:
>> As you are running a 3.14 kernel, you probably missed this fix
>> 5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can
>> you please check?
> 
> I stumbled over this commit but somehow managed to ignore it. Anyway, I
> upgraded to 4.1, now the application shows the expected behavior.
> 
>>> As far as I understand, I have to call sched_yield() if the the
>>> execution time of one loop iteration is either not constant or unknown
>>> (both cases being very likely), because if I do not, a new loop
>>> iteration could be started if the time budget is not empty.
>>>
>>
>> It depends. The sched_yield() semantic for SCHED_DEADLINE might
>> be used to implement some sort of reclaiming mechanism (not
>> there yet) where you inform the scheduler that you are not going
>> to use the remaining runtime in this period; and the scheduler
>> could recycle this spare runtime for other tasks that are running
>> short of it.
>>
>> However, I'd say that in your case you can also live without it.
>> SCHED_DEADLINE can handle sporadic tasks, it depends on how you
>> implement your userspace loop I guess. If you just check the active
>> flag, and this flag is always set, you are right that you may
>> end up executing back to back, though; in which case it seems that yield
>> semantic could do the trick.
> 
> Since samples are generated and the resulting curve looks like it was
> sampled with a constant frequency, I think that sched_yield() is to be
> used in this context. Before I used sched_yield(), I had to use some
> sleep statements, which made the sample frequency not deterministic and
> filled the CPU up. Now it seems to work pretty well.
> 

Great!

Is there any way you can share your application sources? Maybe
it is already on Github or something? I'd be really curious to
have a look at it :).

> Congrats on the deadline scheduler - it is a great way to introduce some
> real-time capability - and thank you for your help.

Sure, no problem. Thanks a lot for asking your question on the
list!

Best,

- Juri


      reply	other threads:[~2015-08-12 10:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-10 20:47 Question about SCHED_DEADLINE and sched_yield() usage Michael Riesch
     [not found] ` <55C9D32A.4030506@riesch.at>
2015-08-11 11:55   ` Juri Lelli
2015-08-12  9:10     ` Michael Riesch
2015-08-12 10:52       ` Juri Lelli [this message]

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=55CB2575.4060201@arm.com \
    --to=juri.lelli@arm.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael@riesch.at \
    /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.