Date: Fri, 21 Sep 2001 23:13:21 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: John Baldwin <jhb@FreeBSD.org> Cc: Josef Karthauser <joe@tao.org.uk>, Dag-Erling Smorgrav <des@ofug.org>, Jun Kuriyama <kuriyama@imgsrc.co.jp>, Julian Elischer <julian@FreeBSD.org>, current@FreeBSD.org, Julian Elischer <julian@elischer.org> Subject: Re: Problems with interrupts on -current. Message-ID: <3BAC2C01.64BC7F1B@mindspring.com> References: <XFMail.010921145354.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > Bah, we leave interrupts disabled during fast interrupt handlers, so this > should be fine in -current since the softclock swi_sched() uses SWI_NOSWITCH > (there is no NOSWITCH flag in a preemptive kernel, it's automatic and that is > what bit the preemption kernel). I think you will see this problem elsewhere, as time goes on. It is reasonable to leave ethernet card interrupts disabled, in order to load-shed prior to having to handle an interrupt, as a means of receiver livelock avoidance. Were you to implement a fair share scheduler to ensure that your web server or firewall got a chance to process incoming packets in a user space process to completion, rather than spending all its time fielding hardware interrupts to the exclusion of all else, part of the implementation would be to disable interrupts on the card when the kernel-to-user queue hit a certain depth, and not reenable them until it hit a corresponding low water mark, at some later time. A reasonable approximation of this would establish high and low watermarks on mbuf usage, and not reenable interrupts if there were less than some low watermark of mbufs free. Then on the freeing of mbufs, the reenables would be delayed until more than a high watermark of mbufs had been freed back to the system. Jeff Mogul, of DEC Western Research Laboratories, suggested this approach in 1994. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BAC2C01.64BC7F1B>