Improve system latency during harddisk access
freebsd at damnhippie.dyndns.org
Sun Dec 2 18:47:37 UTC 2012
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
> 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?
More information about the freebsd-arm