Re: Flush requests not going through IO scheduler

[Jan Kara]

On Mon 02-11-15 12:52:26, Jeff Moyer wrote:
> Jan Kara <jack@xxxxxxx> writes:
> 
> > Hello,
> >
> > when looking into a performance issue, I've noticed one interesting thing
> > in blktrace data:
> 
> Hi Jan,
> 
> Do you have a reproducer I can run?

So I don't have a reproducer that would trigger a situation where we are
idling while there is request queued. However the following is easy to
trigger:

  8,0   67       43     0.000064884  1958  D  WS 2499459168 + 104 [jbd2/sda5-8]
  8,0   67       44     0.000222208     0  C  WS 2499459168 + 104 [0]
  8,0   67        0     0.000232553     0  m   N cfq1958SN / complete rqnoidle 1
  8,0   67        0     0.000234002     0  m   N cfq1958SN / set_slice=30
  8,0   67        0     0.000234984     0  m   N cfq1958SN / Not idling.  st->count:1
  8,0   67        0     0.000236353     0  m   N cfq1958SN / arm_idle: 2 group_idle: 1
  8,0   67        0     0.000236832     0  m   N cfq schedule dispatch
  8,0   67       45     0.000259492  1958  A FWFS 2499459272 + 8 <- (8,5) 621525192
  8,0   67       46     0.000259994  1958  Q FWFS 2499459272 + 8 [jbd2/sda5-8]
  8,0   67       47     0.000262466  1958  G FWFS 2499459272 + 8 [jbd2/sda5-8]
  8,0   67       48     0.000263164  1958  I FWFS 2499459272 + 8 [jbd2/sda5-8]
  8,0   67       49     0.000389821     0  D  WS 2499459272 + 8 [swapper/67]
  8,0   67       50     0.000439548     0  C  WS 2499459272 + 8 [0]
  8,0   67       51     0.000556711     0  C  WS 2499459272 [0]
  8,0   67        0     0.004387444     0  m   N cfq idle timer fired

Here we dispatch the flush request quickly but only because we queued kick
of the queue in IO completion of the previous request. If jbd2 were 120 us
slower in submitting the flush request, it would miss the kick and the
request would end up waiting until the idle timer fires.

To trigger this you just need a rotational storage with write back cache,
slice_idle & group_idle enabled, mount ext4 on top of it. Any trasaction
commit will end up looking like this.

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/