Date: Wed, 22 Nov 2000 12:06:41 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Drew Eckhardt <drew@PoohSticks.ORG> Cc: freebsd-hackers@FreeBSD.org Subject: RE: Interrupt threads Message-ID: <XFMail.001122120641.jhb@FreeBSD.org> In-Reply-To: <200011220146.eAM1kFh09832@chopper.Poohsticks.ORG>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-Nov-00 Drew Eckhardt wrote: > For reasons beyond my control, I'm stuck using FreeBSD in a real time > system and am violating my timing constraints when too many SCSI commands > complete in a short time frame and starve one of my userland real time > processes. > > If the interrupt handler wokeup a kernel thread running at a lower > real-time priority than my application which disabled the interrupt > on the PIC/APIC, ran the handler, and re-enabled the line on the > PIC/APIC my problems should go away. > > -CURRENT supposedly uses threads for interrupts. Is there a more specific > description of what it does archived somewhere? Assuming familiarity > with the interrupt code and a cursory but improving understanding of the > scheduler, how messy would it be to retrofit that code to -stable or > 3.1-stable ? There's no good description of what it does, no. :( Basically, it does do what you ask. You could make a given thread interrupt driven by registering a kernel thread using kthread_create() kind of like inthand_add() in -CURRENT does (though you will need to use a different priority for it). Have that kthread run your interrupt handler using something similar to ithd_loop() in i386/isa/ithread.c. Then, when you register an interrupt handler, have the function it calls basically do the equivalent of sched_ithd() in ithread.c. Instead of using the sched_lock to protect the runqueue, use splhigh() instead. Doing this wouldn't involve any changes to the existing assembly code. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001122120641.jhb>