Re: [RFC]block: add flush request at head

[Shaohua Li <shaohua.li@intel.com>]

On Tue, 2011-04-26 at 19:29 +0800, Tejun Heo wrote:
Hi Thejun,
> On Tue, Apr 26, 2011 at 08:49:15AM +0800, Shaohua Li wrote:
> > On Mon, 2011-04-25 at 16:21 +0800, Tejun Heo wrote:
> > > Hello, Shaohua.
> > > 
> > > On Mon, Apr 25, 2011 at 09:01:59AM +0800, Shaohua Li wrote:
> > > > this is a regression from 2.6.39-rc2 compared to 2.6.39-rc1, so this
> > > > isn't related to the flush rewritten. Workload is sysbench fileio,
> > > > please see the first mail at the thread for detail.
> > > 
> > > Understood.  Let's talk on the other thread.
> >
> > This issue isn't related to the optimization patch in another thread.
> > And that patch can't recover the regression, which does improve
> > throughput even without the regression. So please look at issue again.
> 
> IIUC, the regression happened because, before, back-to-back flushes
> were basically optimized out by hardware but, after, due to regular
> writes thrown into the mix, aren't.  If that's the case, I would still
> prefer to solve this from issue side instead of completion if possible
> (it might not be tho).
> 
> Or is the latency introduced for each flush actually making difference
> for the specific benchmark?  Hmmm... maybe that's the case given that
> your patches merging back-to-back flushes doesn't recover the whole
> regression.
The reason is quite subtle ad the queue just has two requests at most
time. Say we have f1, w1, f2, f1 is running and f2 is requeued.
Without the regression, we run f1, f2, w1
with the regression, we run f1, w1, f2
Without the regression, f2 finishes quite quickly and it appears we run
more writes before run a flush.

If you want to check the problem, you should use sata, which gives a lot
of requeue. high-end drive might not be good to investigate the problem.

Thanks,
Shaohua