|Seigo Tanimura||Jun 20, 2002 3:34 am|
|Seigo Tanimura||Jun 20, 2002 3:43 am|
|Terry Lambert||Jun 20, 2002 4:18 am|
|Bosko Milekic||Jun 20, 2002 6:12 am|
|Robert Watson||Jun 20, 2002 11:19 am|
|Bosko Milekic||Jun 20, 2002 11:30 am|
|Gary Thorpe||Jun 20, 2002 12:43 pm|
|Terry Lambert||Jun 20, 2002 7:23 pm|
|Terry Lambert||Jun 20, 2002 7:46 pm|
|Bosko Milekic||Jun 20, 2002 7:54 pm|
|Bosko Milekic||Jun 20, 2002 8:04 pm|
|Jonathan Lemon||Jun 20, 2002 8:06 pm|
|Chuck Paterson||Jun 20, 2002 8:31 pm|
|Bosko Milekic||Jun 20, 2002 8:41 pm|
|Terry Lambert||Jun 20, 2002 8:47 pm|
|Bosko Milekic||Jun 20, 2002 9:01 pm|
|Terry Lambert||Jun 20, 2002 9:15 pm|
|Julian Elischer||Jun 20, 2002 11:27 pm|
|Julian Elischer||Jun 20, 2002 11:42 pm|
|Terry Lambert||Jun 21, 2002 12:58 am|
|Terry Lambert||Jun 21, 2002 1:18 am|
|Julian Elischer||Jun 21, 2002 10:10 am|
|Gary Thorpe||Jun 21, 2002 10:38 am|
|David O'Brien||Jun 21, 2002 1:52 pm|
|Terry Lambert||Jun 21, 2002 3:45 pm|
|Julian Elischer||Jun 21, 2002 3:50 pm|
|Terry Lambert||Jun 21, 2002 4:25 pm|
|Alfred Perlstein||Jun 21, 2002 4:37 pm|
|Julian Elischer||Jun 21, 2002 5:25 pm|
|Alfred Perlstein||Jun 21, 2002 6:11 pm|
|Julian Elischer||Jun 21, 2002 6:34 pm|
|Bernd Walter||Jun 22, 2002 4:33 am|
|Seigo Tanimura||Jun 25, 2002 2:22 am|
|John Baldwin||Jun 26, 2002 11:10 am|
|Terry Lambert||Jun 28, 2002 1:13 pm|
|Seigo Tanimura||Jul 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|
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.
To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message