From owner-freebsd-hackers Wed Nov 22 12: 6:45 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2BE9137B4C5 for ; Wed, 22 Nov 2000 12:06:43 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAMK6U045303; Wed, 22 Nov 2000 12:06:30 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200011220146.eAM1kFh09832@chopper.Poohsticks.ORG> Date: Wed, 22 Nov 2000 12:06:41 -0800 (PST) From: John Baldwin To: Drew Eckhardt Subject: RE: Interrupt threads Cc: freebsd-hackers@FreeBSD.org Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 -- 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