Ummmm... I've been looking at the code and currently I think the best option is yank out plug merging for this merge window. Bypassing rqhash for request merging doesn't seem like a good idea. rqhash itself is, at this point, redundant and the limitation that it can only find requests by the ending sectors lead to weird designs. The single ->last_merge was okay but the recursive back merging is just ugly. What it should be doing is trying back merge and then front merge once for each request insertion as the usual merge path does. We can't do attempt_back/front_merge() for INSERT_MERGE at this point because elv_latter/former_request() only works for requests which are already on elevator and, unfortunately, putting a request onto cfq may kick the queue directly and the request might already be gone by the time we try to merge it. For this merge window, I think we better just disable INSERT_MERGE. A mid-term solution could be changing elevator interface such that elevator_add_req_fn() doesn't kick the queue directly but notify elevator core that the queue needs kicking via return value, so that merging can happen before kicking the queue. Note that there's a caveat here. Merging might make kicking unnecessary or wrong. Better solution would be changing elevator merge logic so that it has "give me request closest to this offset" interface and then use prev/next from there to find out merge candidates for both bio-rq and rq-rq merges and just kill rqhash. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
