Date: Fri, 28 Jun 2002 13:13:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, arch@FreeBSD.org Subject: Re: multiple threads for interrupts Message-ID: <3D1CC378.5377CDB9@mindspring.com> References: <XFMail.20020626141109.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3D1CC378.5377CDB9>