From owner-freebsd-arm@FreeBSD.ORG Sun Dec 2 18:47:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E339403 for ; Sun, 2 Dec 2012 18:47:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 5972B8FC1B for ; Sun, 2 Dec 2012 18:47:36 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qB2IlZJr032307 for ; Sun, 2 Dec 2012 11:47:35 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qB2IlDHb044801; Sun, 2 Dec 2012 11:47:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Improve system latency during harddisk access From: Ian Lepore To: Matthias Reyelt In-Reply-To: <201211290655.39031.Matthias.Reyelt@brunel.de> References: <201211280842.51271.Matthias.Reyelt@brunel.de> <201211290655.39031.Matthias.Reyelt@brunel.de> Content-Type: text/plain; charset="us-ascii" Date: Sun, 02 Dec 2012 11:47:12 -0700 Message-ID: <1354474032.1140.14.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 18:47:37 -0000 On Thu, 2012-11-29 at 06:55 +0100, Matthias Reyelt wrote: > Yes, I admit there's room for clarification: > > On the system there's one task (process), which is timer controlled and runs > every 50ms. The task therefore has only 50ms to finish its cycle. This task > doesn't access the harddisk at all. Generally, there is no performance > problem. > The harddisk shall be used for logging etc. > However, as soon as I log onto the system and do an 'ls' or so, the cyclic > task produces an overrun. It looks as if harddisk access may block the > complete system for 15..20ms sometimes. > > So I am trying to throttle the harddisk I/O so that it doesn't block the rest > of the system. I have tried to renice processes to have increased priority on > the cyclic task. > > Currently we use HZ=1000 and 4BSD scheduler. Also preemption does not improve > the responsiveness. Seems the CPU hangs for some time waiting for the disk. That does sound unusual. Is there anything that looks suspicious in dmesg, especially anything about interrupts? In the boot-time dmesg output, do the interrupt numbers listed for the sata driver look right for that hardware? Not that I can promise a solution of course, but the more info you post the better the chance that someone can offer advice. Useful things include dmesg, kernel config, make.conf and src.conf if they're not empty, the .dts file that describes the devices. Hmmm. The output of vmstat -i might be good to look at. It might be interesting to use dd to continuously read from and/or write to the disk, and look at things like vmstat -i or any other observations you can think to make under those kind of conditions. For example, does the problem become steady if the disk IO is continuous, or is it only an intermittant delay of your app even when the IO is continuous? Is there any network or other IO activity going on when this glitches happen? -- Ian