Date: Tue, 29 Apr 2003 14:04:51 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-arch@FreeBSD.ORG Subject: Re: lots of malloc(M_WAITOK)'s in interrupt context from camisr Message-ID: <XFMail.20030429140451.jhb@FreeBSD.org> In-Reply-To: <200304290438.h3T4cdHE069528@arch20m.dellroad.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29-Apr-2003 Archie Cobbs wrote: > Bruce Evans wrote: >> > I would tend to think that while sleeping in interrupt threads >> > should be avoided, it should only be avoided "at reasonable cost", >> > not "at any cost". >> >> I think it may actually work now in some cases, since there is now an >> ithread context to sleep on, but camisr() in general is not such a > > [ moving this followup to -arch ] > > Random thought.. it's always seemed unnatural to me to say that > interrupt threads can't sleep. > > Why couldn't the system be designed so that if an interrupt thread > tried to sleep, it would actually sleep but atomically (a) detach > itself from the interrupt and (b) spawn a new thread to handle future > interrupts. I.e., sleep with "on demand" additional interrupt thread > creation. > > To avoid reentrancy problems, we would probably also want to block > re-entry into the same interrupt handler function until the original > handler returned. > > If you did this, code wouldn't have to "know" whether it was running > in an interrupt. > > Of course, for efficiency you don't want to do a lot of sleeping > while handling interrupts, but in practice the need to probably only > arises very rarely (e.g., insertion/removal, ifconfig up/down, etc.). If you need to do more work in your interrupt routine than just wakeups and dinking with registers, you can always wake up a software interrupt handler or some other random kthread to do things that take a long amount of time. Sleeping in an interrupt thread would destroy interrupt latency far worse than it is now. I'm sure we can all agree that that would be unacceptable. Rather than making the interrupt thread implementation very complex with magical spawning kthreads and such, I would prefer that driver authors kick up software interrupt threads and the like on their own and keep the ithread implementation simple. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030429140451.jhb>