> Date: Wed, 18 Apr 2001 01:38:14 -0300 (BRST)
> From: Rik van Riel <[EMAIL PROTECTED]>
>
> > Hence, my philosophy is that task switching and preemption are
> > necessary evils because hardware does not perfectly accomodate
> > software. If we must, we must... otherwise, use co-op switching as
>
On Wed, 18 Apr 2001, E.B. Dreger wrote:
> For minimal CPU utilization, it would be nice skip task switching,
> period. Run something to completion, then go on to the next task.
> Poll without ever using an interrupt.
[snip]
> Hence, my philosophy is that task switching and preemption are
> ne
Going back to basic principles:
For minimal CPU utilization, it would be nice skip task switching, period.
Run something to completion, then go on to the next task. Poll without
ever using an interrupt.
The problem is that latency becomes totally unacceptable.
So now let's go to the other extr
> Date: Wed, 18 Apr 2001 00:04:12 -0300 (BRST)
> From: Rik van Riel <[EMAIL PROTECTED]>
>
> Not true. Interrupts work worse than polling because the interrupt
> top halves can keep the CPU busy, whereas with polling you only
Top halves and _task switching_. Again, in a well-written handler with
On Tue, 17 Apr 2001, Matt Dillon wrote:
> Under a full load polling would work just as well as an interrupt.
> With NT for the network tests they hardwired each NIC to a particular
> CPU. I don't know if they did any polling or not.
Not true. Interrupts work worse than polling becau
> IIRC, didn't the NT driver for some NIC (Intel?) switch to polling,
> anyway, under heavy load? The reasoning being that you _know_ that you're
> going to get something... why bother an IRQ hit?
THis is very interesting. How does this affect performance?
JAn
To Unsubscribe: send mail to [EMA
> Date: Tue, 17 Apr 2001 19:34:56 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> Yes. Also NICs usually have circular buffers for packets so, really,
> only one cpu can be processing a particular NIC's packets at any given
> moment.
We could always have a mutex for each NIC's ring buff
:IIRC, didn't the NT driver for some NIC (Intel?) switch to polling,
:anyway, under heavy load? The reasoning being that you _know_ that you're
:going to get something... why bother an IRQ hit?
:
:That said, IRQ distribution sounds like a good thing for the general case.
Under a full load p
> Date: Tue, 17 Apr 2001 19:06:08 -0700 (PDT)
> From: Matt Dillon <[EMAIL PROTECTED]>
>
> They don't have to be. If you have four NICs each one can be its own
> interrupt, each with its own mutex. Thus all four can be taken in
> parallel. I was under the impression that BSDI had achieved that
> Date: Tue, 17 Apr 2001 18:28:40 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>
>
> 1) interrupts are again fan-in, meaning if you block an interrupt
> class on one cpu you block them on all cpus
When would this be a bad case? i.e., if an interrupt [class] must be
blocked, would we
> Date: Tue, 17 Apr 2001 21:20:45 -0400
> From: Bosko Milekic <[EMAIL PROTECTED]>
>
> What happens if we get an interrupt, we're thinking about servicing
> it, about to check whether we're already holding a mutex that may
> potentially be used inside the mainline int routine, and another CPU
> be
11 matches
Mail list logo
