Re: [LAU] i5 Hyper-Threading, BIOS settings and Arch n00b pointers

From: Fons Adriaensen <fons@email-addr-hidden>
Date: Fri Aug 29 2014 - 19:01:11 EEST

On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise wrote:

> that's interesting, it seemed promising at first ... so this is for
> being certain that particular and predictable sized tasks will get
> scheduled in time for their own individual deadlines, and I guess
> finding out immediately that something can't be guaranteed

Yes. On a single CPU machine, if the API accepts your parameters
(the condition involving the P_i and T_i is satisfied), then in
theory things should work up to 100% CPU. In practice a bit less,
due to implementation losses. The strange thing is that the same
algorithm can not provide the same guarantee on multi-CPU systems.
All it can do in that case is provide an upper bound on by how
much deadlines will be missed. There seems to be no solution for
this somewhat counter-intuitive result.

> most audio tasks need to be done as soon as possible since they are
> of less predictable duration, are inter-dependant and all work
> together towards essentially the same deadline ...

Yes, it's those dependencies and the fact that the whole set of tasks
has a common deadline instead of each an individual one which doesn't
fit into the scheme. It's really meant for e.g. servers which should
use a well defined percentage of the time for each of a number of tasks.
Meeting the deadlines is in fact not the end, but the means by which
this is achieved by the new scheduler.

> in multi core machines with a set of audio tasks taking most of the
> available processing is scheduling the tasks with the most depending
> on them earliest, hence putting tasks on queues with various
> priorities makes a lot more sense.

The most common case in our world is all tasks having the same period.
Then you schedule them on their dependencies, and nothing else. The
exception would be algorithms such as used in zita-convolver in which
part (or even most of) the work is done in larger periods, which are
all an exact multiple (even power of 2) of Jack's one. Rate-monotonic
scheduling (giving the tasks with larger periods lower priority) works
very well in that case, up to full CPU usage, provided all app use the
same mapping from period size to priority.

Ciao,

-- 
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Fri Aug 29 20:15:04 2014

This archive was generated by hypermail 2.1.8 : Fri Aug 29 2014 - 20:15:04 EEST