On Tue, Jan 30, 2018 at 01:32:25PM -0700, Jens Axboe wrote:
> On 1/30/18 1:30 PM, Keith Busch wrote:
> > On Tue, Jan 30, 2018 at 08:57:49AM -0700, Jens Axboe wrote:
> >>
> >> Looking at the disassembly, 'n' is 2 and 'segments' is 0xffff.
> >
> > Is this still a problem if you don't use an IO scheduler? With deadline,
> > I'm not finding any path to bio_attempt_discard_merge which is where the
> > nr_phys_segments is supposed to get it set to 2. Not sure how it could
> > becmoe 0xffff, though.
>
> blk_mq_make_request() -> blk_mq_sched_bio_merge() -> __blk_mq_sched_bio_merge()
> -> blk_mq_attempt_merge() -> bio_attempt_discard_merge()
That's the calls only if you don't have an elevator_queue, right? With
deadline, it looks like it goes through this path (ftrace confirms):
__blk_mq_sched_bio_merge() -> dd_bio_merge() -> blk_mq_sched_try_merge()
Which doesn't have a case for ELEVATOR_DISCARD_MERGE.
Relavant function_graph:
46) | blk_mq_make_request() {
46) 0.133 us | blk_queue_bounce();
46) 0.370 us | blk_queue_split();
46) 0.314 us | bio_integrity_prep();
46) 0.081 us | blk_attempt_plug_merge();
46) | __blk_mq_sched_bio_merge() {
46) | dd_bio_merge() {
46) 0.792 us | _raw_spin_lock();
46) | blk_mq_sched_try_merge() {
