[linux-audio-user] gnome-terminal performance

[Lee Revell]

On Sat, 2004-07-31 at 23:52, Florin Andrei wrote:
> On Sat, 2004-07-31 at 17:03, Lee Revell wrote:
> > On Sat, 2004-07-31 at 18:41, Florin Andrei wrote:
> > > On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
> > > 
> > > > If jackd were running SCHED_FIFO aka realtime, and gnome-terminal as a
> > > > normal priority process, it would be a bug (priority inversion) if
> > > > gnome-terminal *ever* interfered with jackd's operation.
> > > 
> > > Well, i thought Linux can provide only soft realtime, so the
> > > interference is not totally out of question (like it would be on systems
> > > that can do hard or "true" realtime). Am i missing something?
> > 
> > It's not "hard realtime", which is where missing a deadline is
> > considered a fatal error, and is *never* allowed.  The Mars Rovers are a
> > hard RT - if you are *ever* too late in responding to a 'move wheel'
> > command, that's it - mission over.
> 
> Dude, i am aware of the difference between soft and hard realtime.

Sorry, that came off totally pedantic, I thought I was replying to the
list vs. email... you would be surprised at how many people *on LKML*
don't understand the distinction.

>  I was
> merely pointing out that your strong statement ("it would be a bug
> (priority inversion) if gnome-terminal *ever* interfered with jackd's
> operation") coresponds to the hard realtime situation, while Linux is
> (to my best knowledge) soft realtime.

Ok, 'interfere' is too weak.  It would be a bug if any normal priority
process caused a SCHED_FIFO process to miss a deadline.

Well, the tricky thing about soft and hard realtime is that they don't
really say anything about the system, but about the guarantees you
willing to make about it, you have to take intent into account.  I say
that that is a bug because I think Ingo would consider it one, due to
his definition of how preemption is supposed to work - with the fully
preemptible kernel it is by definition a bug if you have a SCHED_FIFO
process getting blocked by a normal one.  This property (no priority
inversions) does not make it hard realtime, because you need to do more
- before redirectable irqs an interrupt handler would preempt any
process any time an interrupt occurred, potentially causing your
SCHED_FIFO process to get blocked and miss a deadline.  So preventing
priority inversion is one half of the problem, you also need a way to
keep interrupts from blocking your process, or vice versa, if you want
to make a real time guarantee about interrupt response times.  Those two
ingredients (actually three because the scheduler becomes increasingly
important once irqs are threaded) are the building blocks for hard-RT,
which is what I think Ingo means about the latest changes making the
kernel hard-RT capable.

Lee