Hello, On Wed, Jun 04, 2014 at 01:47:36PM +0200, Paolo Valente wrote: > > I think I'm a bit confused because it's named "early" queue merge > > while it actually moves queue merging later than cfq - set_request() > > happens before bio/rq merging. > > > There is probably something I am missing here, because, as can be seen in blk-core.c, > around line 1495, elv_set_request() is invoked in the context of the get_request() function, > which in its turn is called from blk_queue_bio() *after* attempting both a plug merge > and a merge with one of the requests in the block layer's cache. The first > attempt is lockless and doesn't involve the I/O scheduler, but the > second attempt includes invoking the allow_merge_fn hook of the scheduler > (elv_merge() -> elv_rq_merge_ok() -> elv_iosched_allow_merge()). Ah, you're right, set_request doesn't happen if a bio is merged into an existing request. > > Oh, as long as it makes measureable difference, I have no objection; > > however, I do think more explanation and comments would be nice. I > > still can't quite understand why retrying on each merge attempt would > > make so much difference. Maybe I just failed to understand what you > > wrote in the commit message. > > If we remember well, one of the problems was exactly that a different request > may become the head request of the in-service queue between two rq merge > attempts. If we do not retry on every attempt, we lose the chance > to merge the queue at hand with the in-service queue. The two queues may > then diverge, and hence have no other opportunity to be merged. > > > Is it because the cooperating tasks > > issue IOs which grow large and close enough after merges but not on > > the first bio issuance? If so, why isn't doing it on rq merge time > > enough? Is the timing sensitive enough for certain workloads that > > waiting till unplug time misses the opportunity? But plugging should > > be relatively short compared to the time actual IOs take, so why would > > it be that sensitive? What am I missing here? > > The problem is not the duration of the plugging, but the fact that, if a request merge > succeeds for a bio, then there will be no set_request invocation for that bio. > Therefore, without early merging, there will be no queue merge at all. > > If my replies are correct and convince you, then I will use them to integrate and > hopefully improve the documentation for this patch. Ah, okay, so it's about missing the chance to look for cooperating queues when merge succeeds. Yeah, that makes a lot more sense to me. If that's the case, wouldn't it be better to try finding cooperating queues after each merge success rather than each allow_merge() invocation? And let's please document what we're catching with the extra attempts. Thanks. -- tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
