Re: bonnie++ uninterruptible under heavy I/O load

[Jens Axboe]

On Fri, Mar 11 2005, Fabio Coatti wrote:
> Alle 16:16, venerdì 11 marzo 2005, Jens Axboe ha scritto:
> > On Fri, Mar 11 2005, Simone Piunno wrote:
> > > Alle 14:29, venerdì 11 marzo 2005, Baruch Even ha scritto:
> > > > echo t > /proc/sysrq-trigger
> > >
> > > Before killing bonnie:
> >
> > I'm guessing your problem is that bonnie dirtied tons of data before you
> > killed it, so it has to flush it out. If you run out of request entries,
> > you will get to sleep uninterruptibly on those while the data is
> > flushing. I don't see anything unexpected here, it is normal behaviour.
> 
> The real issue here is that under heavy I/O activity (bonnie is a good
> way to emphasize the concept), even caused by only one task, the
> system becomes quite unresponsive and "sluggish". The same can be seen
> under a gentoo "emerge --metadata", and slocate has the same effect.
> The problem is not only related to desktop, but i.e. on a dual opteron
> il takes several seconds to have an "ls" output (on a nearly empty
> dir) or simply to log in using ssh.  It seems to me that I/O scheduler
> gives high priority to the running process and any other request is
> delayed to the point that the responsiveness of a desktop becomes poor
> (say, to open a "K" menu takes several seconds on a pIV 2.8G HT).  In
> every case, we seen that the I/O bound processes are stuck in "D"
> state, the same stands for pdflush and kswapd.

I'd guess that your problem is queueing, if you have a ton of pending
requests in the hardware it will take forever to get a new request
through. There's nothing the io scheduler can do to help you there,
really. The /proc/driver/cciss/cciss0 you originall posted, was that
from before or after running bonnie++? I have no latency experience with
cciss, at least IDE/SATA/SCSI should work alright.

Actually the CFQ that will be in the next -mm release could help you
out, it limits the hardware queue for latency reasons.

-- 
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/