Messages in this thread | | | Date | Sat, 11 Jun 2005 18:31:42 +0200 (METDST) | From | Esben Nielsen <> | Subject | Re: [PATCH] local_irq_disable removal |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |