Messages in this thread | | | Date | Tue, 21 Mar 2000 10:55:19 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Tue, 21 Mar 2000, Roger Larsson wrote: > > Linus Torvalds wrote: > > > > On Sun, 19 Mar 2000, Rogier Wolff wrote: > > > > > > How about making "preemptive kernel" a "default-on" option on 2.4pre > > > and a "default-off" option on the real 2.4 kernel? > > > > No, it's definitely too experimental - there are places that play games > > with the irq state etc, so there can be things that need quite a lot of > > debugging to get the threaded-UP case working fine. > > Won't a "preemtive UP kernel" behave more like a SMP kernel? And aid to > find really nasty SMP bugs?
In theory, yes.
In practice, there are places that know how spinlocks work, and do things with them that would be illegal in the preemptive UP kernel. Nor many, and maybe I'm pessimistic, but I would not be in the least surprised if some random driver somewhere does something like
spin_lock_irq(&io_request_lock); ... spin_unlock(&io_request_lock); ... __sti();
which is entirely legal on SMP. But it would be hugely illegal on threaded UP with the spinlock optimizations, because the "unlock" would modify the spinlock count, but the optimzied "lock_irq" would not.
Maybe it doesn't happen. The above is certainly not normal or pretty code, but maybe there would be some reason for it.
So basically there _are_ semantic differences between SMP and threaded UP, and while they are probably few and far between, it still means that a pre-2.4 thing woul dbe ill adviced.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |