Hi Mike.

 >> I think the problem is the current flushing that is not able to
 >> share the I/O bandwith with readers.

 >> Here it is my idea that I am testing since some day ago. It
 >> completly avoid the DoS doing `cp /dev/zero /tmp'. Now a `find`
 >> go fast near as there wouldn't be a `cp /dev/zero /tmp' in
 >> background. It improves (or better it gives you :) the
 >> iteractive response while kflushd is doing its work. It seems to
 >> have no impact on normal write performances. It seems to only
 >> avoid the readers-starvation and I am quite happy with it.

 > This patch cured another DoS... Pine!  If you have tired old
 > disks (me), closing a large (lk) mail-box would freeze the
 > machine for several very annoying seconds while it rewrote the
 > file.  --annoyance ;-)

I have to say that I hadn't looked on that behaviour as a DoS attack,
but that is one delay I will be very happy to see removed.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux  |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch.   |
+----------------------------------------------------------------------+
 * ftp://ftp.MemAlpha.cx/pub/rhw/Linux
 * http://www.MemAlpha.cx/kernel.versions.html


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