Re: [PATCH] local_irq_disable removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 11 Jun 2005, Daniel Walker wrote:

> 
> 
> On Sat, 11 Jun 2005, Esben Nielsen wrote:
> 
> > On Fri, 10 Jun 2005, Daniel Walker wrote:
> > 
> > > On Sat, 2005-06-11 at 01:37 +0200, Esben Nielsen wrote:
> > > [...]
> > > > As far as I can see the only solution is to replace them with a per-cpu
> > > > mutex. Such a mutex can be the rt_mutex for now, but someone may want to
> > > > make a more optimized per-cpu version where a raw_spin_lock isn't used.
> > > > That would make it nearly as cheap as cli()/sti() when there is no
> > > > congestion. One doesn't need PI for this region either as the RT
> > > > subsystems will not hit it anyway.
> > > 
> > > I don't like this solution mainly because it's so expensive. cli/sti may
> > > take a few cycles at most, what your suggesting may take 50 times that,
> > > which would similar in speed to put linux under adeos.. 
> > 
> > We are only talking about the local_irq_disable()/enable() in drivers, not
> > the core system, right? Therefore making it into a mutex will not be that
> > expensive overall.
> 
> No, core system . We're talking about everything, including
> raw_spinlock_t.
>
I think that is a really bad idea then. It only helps on irq-latency. The
rest of the system will see lower performance. It should certainly not be
on as a default thing with PREEMPT_RT. Such low latencies are rarely
needed.

I think extremely low irq-latencies can better obtained with other 
solutions closer to the sub-kernel approach, i.e. taking it completely 
away from the scheduler such that the whole kernel - including the
scheduler, raw_spinlock etc. - runs with irqs enabled.

Actually, I think there should be 3 "levels" of irq-macroes:
 local_irq_disable()      should not compile under PREEMPT_RT (!!)
 raw_local_irq_disable()  should be used within the core kernel code.
 hard_local_irq_disable() for the very low latency interrupt systems.
Under normal circumstances raw_local and hard_local should refer to the
hardware but raw_local can be made into a soft-interrupt state close to
the sub-kernel approach such that one or two very special interupts can
come through.

Esben

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux