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, 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/

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