Agreed. I only thought this was a problem because you said it should
work. ;)
> Try changing drivers/block/deadline-iosched.c:fifo_batch to 16.
Works! A 12x burn succeeded with a parallell dd *and* and make -j20.
Overall disk throughput suffered by a couple MB/s but there was a solid
2 MB/s left for the recorder.
> And the application isn't performing enough caching, perhaps.
Perhaps, but it was a steady downward spiral, and with a read
throughput far lower than needed I think the application would have
had to cache the entire image in order to survive.
> The VM could be fairly easily changed to defer writeback if there is
> read activity happening on the same spindle. Been thinking about
> that (and its relative, early flush) a bit. But that write has
> to go to disk sometime.
Sounds interesting. It seems that this is the sort of behavior is
precisely what some workloads need and precisely the opposite of
what others need. Such is the life of a vm hacker, I suppose. :/
--Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/