Messages in this thread | | | Date | Mon, 13 Mar 2000 12:57:34 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Mon, 13 Mar 2000 yodaiken@fsmlabs.com wrote:
> > > Ok. Ingo: does your "low latency" patch violate this rule? > > > > yep, of course. It's a grave error to schedule during IRQ contexts, and we > > I think you mean: "of course not"!
[ oops, correct :-) ]
> > do have an assert in schedule() so it's plain impossible. The lowlatency > > patch simply works by increasing the effective frequency (occurance) of > > rescheduling (preemption) points [without actually rescheduling more > > often]. > > This is too subtle for me. I don't know how you can make true > the first 2 things without having the third be false.
well, the core of it is really simple:
if (current->need_resched) schedule();
current->need_resched is rarely set, mostly only if a process is getting preempted by a higher priority process. (which is the case we are interested in)
There are two basic cases: there is no 'high priority frequent rescheduler', in which case the above code rarely hits (mostly gets triggered only if some interactive application is used). The other case when there is some latency-sensitive high priority application around - in this case we will likely rescheduler more often, but thats exactly what we were interested in: rescheduling right when the application needs it.
> > Having said this, i now do agree that doing a preemptible kernel (which > > the Linux SMP kernel could become with a small amount of work) is a > > superior solution to this, wrt. latencies. > > Well, to start, it would violate Linus' rule, an old UNIX rule, and your > new IRQ scheme makes it more complex -- you have to make sure to not > switch out of tasks that are handling unacked interrupts. > I don't know how to trade throughput for latency without losing throughput.
we would still not switch out of IRQ contexts. IRQ contexts (including softirqs, tasklets and bhs) are supposed to be atomic and time-bound. A preemptive Linux kernel simply does a context switch if 1) ->need_resched is set 2) we return to a non-IRQ context (which can be either user-space or kernel-space). There is nothing magic about this, SMP does not effectively when two processes are running on two CPUs - instructions get mixed up. You can think of SMP Linux running on a dual-CPU box as a 'very fast scheduler', which schedules instructions from 2 processes to the system bus at the instruction level. The fact that we do not do _explicit_ kernel-code preemption in SMP mode is just a tiny detail ;-)
Ingo
- 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/
| |