lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.319 / U:1.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site