On Sun, Oct 04 2009, Mike Galbraith wrote: > On Sat, 2009-10-03 at 21:49 +0200, Mike Galbraith wrote: > > > It's a huge winner for sure, and there's no way to quantify. I'm just > > afraid the other shoe will drop from what I see/hear. I should have > > kept my trap shut and waited really, but the impression was strong. > > Seems there was one "other shoe" at least. For concurrent read vs > write, we're losing ~10% throughput that we weren't losing prior to that > last commit. I got it back, and the concurrent git throughput back as > well with the tweak below, _seemingly_ without significant sacrifice. > > cfq-iosched: adjust async delay. > > 8e29675: "implement slower async initiate and queue ramp up" introduced a > throughput regression for concurrent reader vs writer. Adjusting async delay > to use cfq_slice_async, unless someone adjusts async to have more bandwidth > allocation than sync, restored throughput. After comitting it yesterday, I was thinking more about this. We cannot do the delay thing without at least doing one dispatch, or we risk starving async writeout completely. This is problematic, as it could cause indefinite delays and this opens up easy DoS attacks from local users. So I'll commit a change that doesn't do the delay at all, basically it just offset the current code by one slice. -- Jens Axboe -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
