Hi, Thank you for your comments. Leroy van Logchem wrote: >The default dirty_ratio on most 2.6 kernels tend to be too large imo. >If you are going to do sustained writes multiple times the size of >the memory you have at least two problems. > >1) The precious dentry and inodecache will be dropped leaving you with >a *very* unresponsive system >2) The amount of dirty_pages which need to be flushed to disk is huge, >taking all VM while the i/o channel takes uninterruptable time toćflush it.
I agree that the default dirty_ratio is too large. What I have observed is that write(2) to a disk only with light load is blocked in balance_dirty_pages() due to heavy write to *another* disk, and doesn't seem to be the same issue as you say. But decreasing dirty_ratio shortens the blocking time also in our experiments. >What we really need is a 'cfq' for all processes -especially misbehaving >ones like dd if=/dev/zero of=/location/large bs=1M count=10000-. >If you want to DoS the 2.6 kernel, start a ever running dd write and >you know what I mean. Huge latencies due the fact that all name_to_inode >caches are lost and have to be fetched from disk again only to be quickly >flushed again and again. I already explained this disaster scenario with >Linus, Andrew and Jens; hoping for a auto-tuning solution which takes >diskspeed per partition into account. I appreciate for your information. Would you know about any progress in this issue? Regards, -- Tomoki Sekiyama & Yuji Kakutani Hitachi, Ltd., Systems Development Laboratory - 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/
