On Sat, 2005-06-11 at 22:23 +0200, Esben Nielsen wrote:
> >
> No because it correctly leaves irqs on but not preemption on.
>
I see your worries now. See below.
> > > The worry is local_irq_disable() (and preempt_disable()). I can undefine
> > > it and therefore find where it is used. I can then look at the code, make
> > > it into raw_local_irq_disable() or try to make a lock.
> > > In many cases the raw-irq disable is the best and simplest when I am only
> > > worried about task-latencies. But now Daniel and Sven wants to use the
> > > distingtion between raw_local_irq_disable() and local_irq_disable() to
> > > make irqs fast.
> >
> > We aim to make IRQ latencies deterministic. This affects preemption
> > latency in a positive way.
> >
> No. If you leave preemption off but irqs on, which is what is done here,
> you get good, deterministic IRQ latencies but nothing for task-latencies -
> actually slightly (unmeassureable I agree) worse due to the extra step
> you have to go from the physical interrupt to the task-switch is
> completed.
>
If its unmeasurable, what is the BIG deal? Don't make me say again that
we need real data here.
> > Anywhere in the kernel that IRQs are disabled, preemption is impossible.
> > (you can't interrupt the CPU when irqs are disabled)
> >
> For me it is the _same_ thing. Equally bad. If preemption is off I don't
> care if irqs are off.
>
So if its the same thing, why are you concerned with the improvement as
is?
> > But you said you are worried about overhead. You have to incur overhead
> > to make task response deterministic.
> >
> > Are you sure you are not just trying to make it FAST?
> >
> Certainly not. I was pressing for priority inheritance forinstance. That
> thing does certainly not make it fast, but it makes use of locks
> deterministic.
>
PI is already in there. I think you are missing some basic concepts here,
for example that IRQs can happen ANYTIME, not just when we happen to enable
interrupts where they have previously been disabled.
I am going to stop responding to this thread until you back up your concerns
with real data, or throw some code out there, that you can back up with real data.
Regards,
Sven
-
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]
