From owner-freebsd-current@FreeBSD.ORG Sat May 10 20:50:06 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6ADC37B401 for ; Sat, 10 May 2003 20:50:06 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9565D43FA3 for ; Sat, 10 May 2003 20:50:05 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id NAA12952; Sun, 11 May 2003 13:49:40 +1000 Date: Sun, 11 May 2003 13:49:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Poul-Henning Kamp In-Reply-To: <22333.1052574519@critter.freebsd.dk> Message-ID: <20030511133513.T74110@gamplex.bde.org> References: <22333.1052574519@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Interrupt latency problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2003 03:50:07 -0000 On Sat, 10 May 2003, Poul-Henning Kamp wrote: > In message <1052570246.27195.6.camel@cf.freebsd-services.com>, Paul Richards wr > ites: > >I'm having real problems with current with heavy disk activity. > > > >When working in X and updating ports which causes a lot of disk activity > >I get *very* poor interactive responses. Keypresses can not appear for > >seconds and mouse movement is very jerky and unresponsive. > > > >I'm wondering if something is holding locks a long time in interrupt > >handlers and causing mouse/keyboard interrupts to be lost? > > We have this lock called "Giant" which we're trying to get rid off... Giant shouldn't cause such enormous latency as several seconds. Most likely, something _outside_ of interrupt handlers is holding Giant for too long. Interrupt handlers are more aware that they shouldn't run for too long, while code running outside of interrupt handlers was mostly written under the assumption that it can run for as long as necessary to do whater it is asked to do. At least on i386's, all interrupts are latched by the lowest levels of the interrupt handling code, so it is almost impossible to lose one completely. Events that the interrupts signal may be lost, depending on how much buffering the interrupting device has. Bruce