Re: Question about SCHED_DEADLINE and sched_yield() usage

[Juri Lelli <juri.lelli@arm.com>]

Hi Michael,

On 11/08/15 11:49, Michael Riesch wrote:
> Hi all,
> 
> I connected two analog-to-digital converters to a BeagleBoneBlack (with
> kernel version 3.14.33-ti-r51.2) and tried to use the deadline scheduler
> to get samples at a constant rate. In my C++/Qt application the ADCs are
> represented by a class which is derived from QThread. The run() method
> is basically:
> 
> run()
> {
>    unsigned int flags;
>    struct sched_attr attr;
>    attr.sched_policy = SCHED_DEADLINE;
>    attr.sched_runtime = 600 * 1000;
>    attr.sched_deadline = 1250 * 1000;
>    attr.sched_period = 1250 * 1000;
>    sched_setattr(0, &attr, flags);
> 
>    while (active) {
>       /* code that gets a sample from adc, takes around 500 ms */
> 
>       sched_yield();
>    }
> }
> 
> to get samples at a rate of 800 Hz. However, once sched_yield() is
> called, the threads do not seem to be scheduled again (no samples are
> acquired and when the application shuts down the threads remain as zombies).
> 

As you are running a 3.14 kernel, you probably missed this fix
5bfd126e80dc "sched/deadline: Fix sched_yield() behavior". Can
you please check?

> 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.

Best,

- Juri