On Wed, Dec 02, 2009 at 08:19:06AM -0500, Paul Davis wrote:
In the general case this would be correct, SCHED_FIFO
does not in any way ensure that threads get a 'fair
share of time'. But this is not the general case.
In cases such as the one discussed, the threads are
triggered at a divisor of Jack's period rate. Each
time they get a quantum of work, perform it, and
wait for the next trigger. They do not try to run
for as long as they can.
The threads do not compete on CPU time: the assumption
is always that there is enough CPU power to perform
all the work. If this is not the case the whole thing
The 'competition' is on the order in which they are
allowed to run, and for that priority is the only
The objective of the priority scheme is to allow all
threads to meet their deadline, not to give them equal
CPU shares. They don't need equal CPU shares anyway,
in most cases the bulk of the work is done by the
lowest priority ones.
An example should make this clear. Assuming the
period size is 256, running the 'Great Hall' reverb
in jconvolver, configured for a minimum partition
size of 256 (no processing delay) will result in the
(you can use -v to see this)
prio = 0, offs = 0, parsize = 256, npar = 3
prio = -1, offs = 768, parsize = 512, npar = 6
prio = -3, offs = 3840, parsize = 2048, npar = 6
prio = -5, offs = 16128, parsize = 8192, npar = 13
The first one is Jack's process thread, this will do the
work for 3 partitions of size 256. The second one will do
6 partitions of size 512, it will be triggered every two
periods. The next one runs every 8 Jack periods, the last
one every 32.
The last three are required to have completed their work
when the next trigger arrives. Their output is actually
only required later, 3 periods after the start for the
size 512, 15 periods for the size 2048, and 31 for the
last. This gives the whole system some robustness it
would not have if everything was planned 'just in time'.
Note that the extra margin is small for small partition
sizes and quite big for the larger ones.
Now if the same reverb is configured to use a minumum
period size of 4096 (because the user can tolerate the
delay and wants less CPU load) this would look different:
prio = -4, offs = 0, parsize = 4096, npar = 2
prio = -5, offs = 8192, parsize = 8192, npar = 14
As you can see the priorities match the partition size.
In this case no work is done in Jack's thread.
Now assume that I would use the scheme of version 1.0.0.
Then the priorities would be
respectively. This would mean that the size 4096 thread
of the second instance would have the same priority as
the size 512 thread of the first. The time required for
the size 4096 calculations could easily be longer than
the period of of the size 256 thread. This would result
in the size 256 thread being late every time it has to
wait for the other to complete, which could happen every
Matching priorities to period size removes this problem,
and ensure that the most urgent work will always be done
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
Linux-audio-user mailing list