Hello, On Wed 17-06-20 17:41:36, Chaitanya Kulkarni wrote: > 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. attempt_merge() is always called so that 'req' is always the request with the lower sector, 'next' is the request with a higher sector, and 'next' is discarded and 'req' is updated. So attempt_merge() always performs only one direction of a merge and I don't think it makes any sence to distinguish back merges and forward merges in this case. So discards don't need any special treatment either AFAICT. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
