linux-kernel - Re: Question about SCHED_DEADLINE and sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <55C9E29B.1050203@arm.com>
Date:	Tue, 11 Aug 2015 12:55:07 +0100
From:	Juri Lelli <juri.lelli@....com>
To:	Michael Riesch <michael@...sch.at>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"juri.lelli@...il.com" <juri.lelli@...il.com>, juri.lelli@....com
Subject: Re: Question about SCHED_DEADLINE and sched_yield() usage

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/