From owner-freebsd-current Fri Sep 21 23:12:38 2001 Delivered-To: freebsd-current@freebsd.org Received: from robin.mail.pas.earthlink.net (robin.mail.pas.earthlink.net [207.217.120.65]) by hub.freebsd.org (Postfix) with ESMTP id AE8CE37B410; Fri, 21 Sep 2001 23:12:35 -0700 (PDT) Received: from mindspring.com (dialup-209.245.141.15.Dial1.SanJose1.Level3.net [209.245.141.15]) by robin.mail.pas.earthlink.net (8.11.5/8.9.3) with ESMTP id f8M6CXH28313; Fri, 21 Sep 2001 23:12:33 -0700 (PDT) Message-ID: <3BAC2C01.64BC7F1B@mindspring.com> Date: Fri, 21 Sep 2001 23:13:21 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: John Baldwin Cc: Josef Karthauser , Dag-Erling Smorgrav , Jun Kuriyama , Julian Elischer , current@FreeBSD.org, Julian Elischer Subject: Re: Problems with interrupts on -current. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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