Messages in this thread | | | Date | Tue, 14 Mar 2000 13:07:21 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Tue, Mar 14, 2000 at 09:54:14PM +0100, Ingo Molnar wrote: > > On Tue, 14 Mar 2000 yodaiken@fsmlabs.com wrote: > > > > people will have the nicely preemptable UP kernel. The latency-quality of > > > the SMP kernel will be much worse than the UP kernel's latency. > > > > I don't see why. Can you explain? > > yep: the SMP kernel will not be preemptible like the UP kernel. > > > Why ? The length of time between scheduler calls under SMP should be > > smaller than the length of time between scheduler calls on UP - no? > > no, they would be bigger because with Linus' suggestion the UP kernel uses > spinlocks to make the kernel fully preemptible - we will be able to > reschedule the kernel in a preemptive way at any point that does not hold > any spinlock (or lock). The SMP kernel would still reschedules in a > 'cooperative' way, because spinlocks would not have this 'collect total > current spinlock count' property (and thus preempting kernel space would > not be allowed).
But the SMP system should do n-times as many user<->kernel transitions and so should still run into preemption points at a high speed: even if each processor schedules less often.
> IMPORTANT: to avoid any misunderstanding, this does not make the SMP > kernel worse in any way than it is right now. But this would be a > (dramatic wrt. latencies!) 'UP-only' improvement, which _feels_ wrong, to > me at least.
If the latencies in question are process schedule latencies, then improving runq operation is the obvious strategy.
> of course it has more footprint than 0 instructions [ == the current SMP > kernel].
I thought that we had had this conversation in another setting and you had argued that cache bloat was absolutely critical path.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.
- 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/
| |