Re: [linux-audio-dev] Soft Realtime Scheduling (was: Re: [gtkmm] [slightly OT] Pipes for multi-threaded apps)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Soft Realtime Scheduling (was: Re: [gtkmm] [slightly OT] Pipes for multi-threaded apps)
From: Roger Larsson (roger.larsson_AT_norran.net)
Date: Tue Jun 18 2002 - 01:59:11 EEST


On Monday 17 June 2002 21.32, nick wrote:
> On Sun, 2002-06-16 at 19:14, Paul Davis wrote:
> > >I know and you did not understand my question (or I did not write it
> > >clear enough). What I asked is if you made a test how good Linux handles
> > >multitasking when there are many threads that want to get 100% of CPU.
> >
> > if they run SCHED_OTHER, then they get timesliced, and they each get a
> > fair share. but read on ...
> >
> > threads in the SCHED_FIFO or SCHED_RR scheduling classes are *not*
> > timesliced. it doesn't matter how much time or cycles the GUI thread
> > takes (it uses SCHED_OTHER) because the RT thread will get the
> > processor pretty much whenever it needs it.
> >
> > the hard part is if you have multiple SCHED_FIFO threads. thats a
> > different story. if you have N threads that each want to use more than
> > 1/N of the cycles and/or have hard scheduling deadlines that each one
> > interferes with, then you have a set of constraints that are hard or
> > impossible to satisfy. but this is an uncommon situation (though by no
> > means totally rare).

(more than 1/N of the cycles) * (N threads) > all available cycles

It wont matter how you schedule this - it will always fail...!!!

How would you like it to be handled? What thread to starve?
If you starve all a little - they will all fail.
If you starve a set - they might be a critical set that makes the application
fail.
If you only starve one - it might be a critical one like the one doing the
final write toward drivers and the application will fail.

The only solution is to let the application writer decide how to set
priorities. With some simple rules:
* Threads that execute in short burst should have higher priority.
* Threads that processes for long time should have low priority.
* Important threads should have higher priority.
* Threads that might overload the rest of the system with unimportant work can
have reduced priority (I can't make up an example for this right now
that fits in the application domain - but concider you have a interrupt driver
that counts events. Above a certain limit it should wake up a handler thread,
but in a otherwise busy system it can wait - since it might have been these
count events that created the overload in the first place, and the driver is
still counting = no event will be lost but handling will be delayed.)

/RogerL

-- 
Roger Larsson
Skellefteċ
Sweden


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Jun 18 2002 - 05:16:18 EEST