Re: [PATCH] local_irq_disable removal

[Sven-Thorsten Dietrich]

On Sat, 2005-06-11 at 19:26 +0200, Thomas Gleixner wrote:
> On Sat, 2005-06-11 at 09:36 -0700, Daniel Walker wrote:
> > 
> > On Sat, 11 Jun 2005, Esben Nielsen wrote:
> > 
> > > For me it is perfectly ok if RCU code, buffer caches etc use
> > > raw_local_irq_disable(). I consider that code to be "core" code.
> > 
> > This distinction seem completly baseless to me. Core code doesn't
> > carry any weight . The question is , can the code be called from real
> > interrupt context ? If not then don't protect it.
> > 
> > > 
> > > The current soft-irq states only gives us better hard-irq latency but
> > > nothing else. I think the overhead runtime and the complication of the
> > > code is way too big for gaining only that. 
> > 
> > Interrupt response is massive, check the adeos vs. RT numbers . They did
> > one test which was just interrupt latency.
> 
> 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.

> 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.

For every example I can find you a corner case.
 
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.

We are merely working to provide alternatives that improve performance.

Sven






-
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/