Date: Tue, 12 Sep 2000 04:26:54 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: arch@freebsd.org Subject: what to do with softinterrupts? Message-ID: <20000912042654.L12231@fw.wintelcom.net>
next in thread | raw e-mail | index | archive | help
There's a problem with softinterrupts: we have only one.
I'm trying to figure out what to do with the situation because
unless I can schedule more than one concurrantly I can't really
test much of what I'm working on, there's also making the input
path concurrant and responsive.
After thinking about it for some time I came up with a solution
for network drivers.
The idea is to keep several spare interrupt threads available for
the network interrupts.
Instead of ether_input() figuring out the type of packet and schduling
a soft interrupt it will:
Swap out its repsonsibility with another spare thread to handle
the interface's hardware interrupt
Perform a callback to the driver to re-enable interrupts
Jump directly into what is now a pseudo-soft-interrupt
This will happen as long as it can reserve a spare thread, and
we're not pre-empting a softinterrupt running(*) in the same protocol
on the same CPU. Otherwise it simply queues and schedules like
before.
(*) running == not blocked on a mutex, if it's blocked on a mutex
we allow another jump from hardware to software to gain concurrancy.
When the softinterrupt is complete it will then recheck its input
queue for mbufs, if there is none it will return to it's state as
an idle interrupt thread making itself free for consumption to
service other devices or stacks.
From my point of view this will give:
better concurrancy, by making the stack less likely to stall
because of blocking while accessing potentially locked objects
less context switching because there's no need to schedule a soft
interrupt unless we are seriously bogged down
Poul-Henning Kamp thought that investigating atomic ops and
keeping most of the current scheme of things would also work.
We'd have to have a softinterrupt bound to each CPU, but as long
as they could proceed without blocking we'd probably be ok.
The problem I see with this is that it sort of tries to get around
the whole interrupt thread idea by going back to non-blocking
interrupts instead of taking the advantage (or performance hit)
of the threads system we have in place.
I'm not dead set on either idea, but I wanted to know what other
solutions people could come up with to address this problem, any
takers? any existing solutions?
thanks,
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000912042654.L12231>