atom feed36 messages in org.freebsd.freebsd-archRe: multiple threads for interrupts
FromSent OnAttachments
Seigo TanimuraJun 20, 2002 3:34 am 
Seigo TanimuraJun 20, 2002 3:43 am 
Terry LambertJun 20, 2002 4:18 am 
Bosko MilekicJun 20, 2002 6:12 am 
Robert WatsonJun 20, 2002 11:19 am 
Bosko MilekicJun 20, 2002 11:30 am 
Gary ThorpeJun 20, 2002 12:43 pm 
Terry LambertJun 20, 2002 7:23 pm 
Terry LambertJun 20, 2002 7:46 pm 
Bosko MilekicJun 20, 2002 7:54 pm 
Bosko MilekicJun 20, 2002 8:04 pm 
Jonathan LemonJun 20, 2002 8:06 pm 
Chuck PatersonJun 20, 2002 8:31 pm 
Bosko MilekicJun 20, 2002 8:41 pm 
Terry LambertJun 20, 2002 8:47 pm 
Bosko MilekicJun 20, 2002 9:01 pm 
Terry LambertJun 20, 2002 9:15 pm 
Julian ElischerJun 20, 2002 11:27 pm 
Julian ElischerJun 20, 2002 11:42 pm 
Terry LambertJun 21, 2002 12:58 am 
Terry LambertJun 21, 2002 1:18 am 
Julian ElischerJun 21, 2002 10:10 am 
Gary ThorpeJun 21, 2002 10:38 am 
David O'BrienJun 21, 2002 1:52 pm 
Terry LambertJun 21, 2002 3:45 pm 
Julian ElischerJun 21, 2002 3:50 pm 
Terry LambertJun 21, 2002 4:25 pm 
Alfred PerlsteinJun 21, 2002 4:37 pm 
Julian ElischerJun 21, 2002 5:25 pm 
Alfred PerlsteinJun 21, 2002 6:11 pm 
Julian ElischerJun 21, 2002 6:34 pm 
Bernd WalterJun 22, 2002 4:33 am 
Seigo TanimuraJun 25, 2002 2:22 am 
John BaldwinJun 26, 2002 11:10 am 
Terry LambertJun 28, 2002 1:13 pm 
Seigo TanimuraJul 12, 2002 2:26 am 
Subject:Re: multiple threads for interrupts
From:Terry Lambert (tlam@mindspring.com)
Date:Jun 28, 2002 1:13:22 pm
List:org.freebsd.freebsd-arch

John Baldwin wrote:

While I worked on only swis, hardware interrupts should suffer from the same issue as well. Thus it would be better to tweak the general interrupt mechanism rather than only the swi subsystem. I will see how that works in the next few days.

Comments and flames are welcome. Thanks a lot.

I think this is mostly a feature rather than a bug. Allowing more than one handler to execute at a time requires you to use a semaphore or some such to coordinate when you actually enable the interrupt source again.

This is only apriori true, if you know the interrupt is shared; I think there might be a way around it, as well, beased on thread counting, but the easies way is a counting semaphore that is reset by threads and triggers an action on the 1->0 boundary. Meanwhile, the threads for the handing of a shared interrupt for some number of devices should be able to proceed to completion simultaneously, unless they have contention for a resource (guess it's a good things ISA interrupts aren't shared ;^)).

I also think that you are better off waiting for KSE to finish and for us to support per-CPU runqueues with binding so that for processes where it makes sense to do this (like netisr and possibly the cam stuff, ktrace is another potential candidate), you use bound per-cpu threads that still belong to the same process to do this.

THis, I really agree with. Without the ability to show a genuine, measurable improvement from going down too far down this road to back up easily, it's really something that you have to be fearful about. I still have not seen one research paper indicating that Interrupt Threads actually improve the overall performance of a system. They are a clever workaround for a chokepoint which might not be a bottleneck.

FWIW, Solaris doesn't use multiple threads for a shared interrupt, instead, when an ithread is awakened, it is bound to the CPU receiving the interrupt until it finishes. If you don't have a copy of Solaris Internals I would recommend getting a copy. :)

It's a good book, event hough Solaris 9 changes again. I'll also note that they have "invented" the buffer cache seperate from the VM (again), to get around the lack of working set quotas, so some things in that book need to be taken with a grain of salt...

We don't have to be the next Solaris, but we can learn a lot by looking at it.

Exactly. I learn things from looking at Microsoft, which most people treat as if they themselves were vampires and Microsoft direct sunlight.

-- Terry

To Unsubscribe: send mail to majo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message