Re: [PATCH] local_irq_disable removal

[Thomas Gleixner]

On Sat, 2005-06-11 at 11:40 -0700, Sven-Thorsten Dietrich wrote:
> > Performance on RT systems is more than IRQ latencies. 
> > 
> > The wide spread misbelief that 
> >   "Realtime == As fast as possible" 
> > 
> > seems to be still stuck in peoples mind.
> > 
> >   "Realtime == As fast as specified"
> > is the correct equation.
> > 
> 
> I think Daniel was referring to the deviations, but it is always good to
> point that out.


I hope, we can agree on this premise for further discussions


> > There is always a tradeoff between interrupt latencies and other
> > performance values, as you have to invent new mechanisms to protect
> > critical sections. In the end, they can be less effective than the gain
> > on irq latencies.
> > 
> 
> Basically you are investing effort to maintain predictability. 
> 
> In order to do that, you somethimes have to put a stitch in before the
> deadline ("in time..."), the effort increases the work = overhead. 
> 
> But if you look at overall time the tasks are waiting you can implement
> optimal scheduling, and maximize throughput.
> 
> This is too complex to argue about here.

Whats too complex? Are you asserting that other people e.g. me, are too
dumb to understand that ?

> For every example I can find you a corner case.

There is everywhere a corner case. Thats nothing new.

> It depends on the application, and you need to decide how to configure
> our kernel if it really matters to what you are doing with Linux.

I completely agree, but your statement just confirms Ebsen's request for
keeping those tweaks as configurable options rather than built in
defaults.

For any RT application the application dictates the constraints and
therefor requires a maximum of configurability.

> We are merely working to provide alternatives that improve performance.

We all do just with a different set of constraints, right ?


tglx


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