Improve system latency during harddisk access
Matthias.Reyelt at brunel.de
Wed Dec 5 14:23:34 UTC 2012
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
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
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
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
More information about the freebsd-arm