Jan, On 6/17/20 7:03 AM, Jan Kara wrote: > Currently blk-mq does not report any event when two requests get merged > in the elevator. This then results in difficult to understand sequence > of events like: > > ... > 8,0 34 1579 0.608765271 2718 I WS 215023504 + 40 [dbench] > 8,0 34 1584 0.609184613 2719 A WS 215023544 + 56 <- (8,4) 2160568 > 8,0 34 1585 0.609184850 2719 Q WS 215023544 + 56 [dbench] > 8,0 34 1586 0.609188524 2719 G WS 215023544 + 56 [dbench] > 8,0 3 602 0.609684162 773 D WS 215023504 + 96 [kworker/3:1H] > 8,0 34 1591 0.609843593 0 C WS 215023504 + 96 [0] > > and you can only guess (after quite some headscratching since the above > excerpt is intermixed with a lot of other IO) that request 215023544+56 > got merged to request 215023504+40. Provide proper event for request > merging like we used to do in the legacy block layer. > > Signed-off-by: Jan Kara <jack@xxxxxxx> The attempt_merge function is also responsible for the discard merging which doesn't have any direction specified in ELEVATOR_XXX identifiers. In this patch we care unconditionally generating back merge event irrespective of the req_op. Do we need to either generate event iff ELEVATOR_BACK_MERGE true case or add another trace point for discard ? given that it may lead to confusion since elevator flags for the discard doesn't specify the direction.
