Messages in this thread | | | Date | Mon, 13 Mar 2000 03:16:38 -0700 | From | yodaiken@fsmlabs ... | Subject | Re: new IRQ scalability changes in 2.3.48 |
| |
On Mon, Mar 13, 2000 at 12:07:41PM +0100, Ingo Molnar wrote: > > On Sun, 12 Mar 2000 yodaiken@fsmlabs.com wrote: > > > > Quite regardless of how you do interrupts: it doesn't matter where youput > > > the ACK's, you always need to make sure that irq masking etc is correct, > > > and you must NOT allow a context switch while an interrupt handler is > > > still running. > > > > 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"!
> 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.
> 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.
-- --------------------------------------------------------- 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/
| |