Date: Wed, 5 Dec 2012 15:13:58 +0100 From: Matthias Reyelt <Matthias.Reyelt@brunel.de> To: Ian Lepore <freebsd@damnhippie.dyndns.org> Cc: freebsd-arm@freebsd.org Subject: Re: Improve system latency during harddisk access Message-ID: <201212051513.58304.Matthias.Reyelt@brunel.de> In-Reply-To: <1354474032.1140.14.camel@revolution.hippie.lan> References: <201211280842.51271.Matthias.Reyelt@brunel.de> <201211290655.39031.Matthias.Reyelt@brunel.de> <1354474032.1140.14.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201212051513.58304.Matthias.Reyelt>