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. -- Fabio Coatti Wireless Solutions SpA - DADA group Services Manager Europe HQ, via Castiglione 25 Bologna http://www.wseurope.com Tel: +390512966811 Fax: +390512966800 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
