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
the next
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
becomes
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
in
: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
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 buffer...
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 [EMAIL
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 because
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 a
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
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
10 matches
Mail list logo
