* Andrea Arcangeli <[email protected]> wrote:
> > you are wrong. This codepath is not running with interrupts disabled on
> > PREEMPT_RT. irqs-off spinlocks dont turn off interrupts on PREEMPT_RT.
>
> Then I'm afraid preempt-RT infringe on the patent [...]
i'd have expected you to say "oops, i was wrong, thanks for the
explanation", but now you come up with a completely nontechnical topic
instead?
> > (there are still some ways to introduce latencies into PREEMPT_RT, but
> > they are not common and we are working on ways to cover them all.)
>
> How can you schedule a task while a spinlock is held? Ok irqs will
> keep going, but how can you reschedule risking to deadlock? As long as
> there are regular spinlocks in any driver out there (i.e. all of them)
> then you can still introduce latencies. It doesn't seem too uncommon
> to me to take a spinlock. [...]
yes, and everything works just fine, if it's deadlock-free under normal
SMP Linux. The key to that is that the whole execution flow is 'flat'.
I.e. _all_ driver code (except a few notable exceptions that dont count)
runs in a thread context. So spinlocks are _never_ recursively taken by
the same thread under PREEMPT_RT - and the scheduler sorts out all the
inter-thread blocking.
This is the basic concept of PREEMPT_RT. [ I have to say that I'm happy
that while you have already written 12 emails into this thread with a
seemingly firm and competent opinion - arguing against various aspects
of PREEMPT_RT - today you finally seem to have gotten closer to
understanding its basics ;-) ]
Ingo
-
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]
