From owner-freebsd-arm@FreeBSD.ORG Wed Dec 5 14:23:34 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 8EEC595C for ; Wed, 5 Dec 2012 14:23:34 +0000 (UTC) (envelope-from Matthias.Reyelt@brunel.de) Received: from mailout-f4.arcor-ip.de (mailout-f4.arcor-ip.de [145.253.3.219]) by mx1.freebsd.org (Postfix) with ESMTP id CF8AE8FC0C for ; Wed, 5 Dec 2012 14:23:33 +0000 (UTC) Received: from mailer2.brunellocal.de (unknown [145.254.28.158]) by mailout-f4.arcor-ip.de (Arcor-IP) with ESMTP id 26B30E33E4; Wed, 5 Dec 2012 15:14:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 01A4824A96; Wed, 5 Dec 2012 15:14:07 +0100 (CET) X-Virus-Scanned: amavisd-new at brunellocal.de Received: from mailer2.brunellocal.de ([127.0.0.1]) by localhost (mailer2.brunellocal.de [127.0.0.1]) (amavisd-new, port 10024) with SMTP id H+2YdSrxdoVw; Wed, 5 Dec 2012 15:14:06 +0100 (CET) Received: from mail-hv.brunel.de (mail-hv.brunellocal.de [192.168.1.234]) by mailer2.brunellocal.de (Postfix) with ESMTP id C8FF02372C; Wed, 5 Dec 2012 15:14:06 +0100 (CET) Received: from bcslx10.bcs.brunel.local ([172.16.1.3]) by 935s02ub.brunellocal.de (Lotus Domino Release 7.0.4FP1) with ESMTP id 2012120515135946-4298 ; Wed, 5 Dec 2012 15:13:59 +0100 Received: from bcspc139.localnet (bcspc139.bcs.brunel.local [172.16.101.98]) by bcslx10.bcs.brunel.local (Postfix) with ESMTP id DABFDFD8C2; Wed, 5 Dec 2012 15:13:59 +0100 (CET) From: Matthias Reyelt Organization: Brunel Communications To: Ian Lepore Subject: Re: Improve system latency during harddisk access Date: Wed, 5 Dec 2012 15:13:58 +0100 User-Agent: KMail/1.13.6 (Linux/2.6.37.6-0.7-desktop; KDE/4.6.0; i686; ; ) References: <201211280842.51271.Matthias.Reyelt@brunel.de> <201211290655.39031.Matthias.Reyelt@brunel.de> <1354474032.1140.14.camel@revolution.hippie.lan> In-Reply-To: <1354474032.1140.14.camel@revolution.hippie.lan> MIME-Version: 1.0 Message-Id: <201212051513.58304.Matthias.Reyelt@brunel.de> X-MIMETrack: Itemize by SMTP Server on HUB93501/Brunel/De(Release 7.0.4FP1|July 20, 2009) at 05.12.2012 03:13:59 PM, Serialize by Router on HUB10149/Brunel/De(Release 7.0.4FP2|June 06, 2010) at 05.12.2012 03:14:06 PM, Serialize complete at 05.12.2012 03:14:06 PM Content-Transfer-Encoding: 7bit Content-Type: Text/Plain; charset="iso-8859-1" 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: Wed, 05 Dec 2012 14:23:34 -0000 Hi, I have done further tests and the problem seems to be related rather to scheduling than to harddisk performance. My test application runs twice and both processes exchange data in a loop which should take 50ms max, otherwise the application gets finished by a timer. The application is rather uneconomic, as it runs through a small for() loop as fast as possible, therefore the CPU load is 100%. Adding a nanosleep() in the loop execution would reduce the CPU load and probably solve this issue. But I would like to tune the scheduler in a way that my test application is able to run one loop within 50 ms (at least). So I think the scheduler should provide about 5ms slices at most, before a process gets kicked out of the CPU. I have played with 4BSD and reducing kern.sched.quantum, but without remarkable effect. I haven't read through the scheduler documentation yet, and I haven't yet tried with the ULE scheduler. If you have some hint where to look that would be great Matthias Am Sonntag, 2. Dezember 2012 19:47:12 schrieb Ian Lepore: > 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