Re: [PATCH v2.6.38-rc5 2/2] block: blk-flush shouldn't call directly into q->request_fn() __blk_run_queue()

[Tejun Heo <tj@kernel.org>]

Hello,

On Mon, Mar 07, 2011 at 02:50:28PM -0500, Jeff Moyer wrote:
> > But yes, it sounds like IDE is violating this rule and that's why it was
> > broken. Even with that, having explicit control of the queue running
> > does make sense.

Yeah, IDE is the only one which actually depends on it.  At the time I
thought more drivers would use the sleeping context but that didn't
happen (yet).  That said, I think it's generally a good idea to
guarantee context on the issue path (the request_lock requirement
makes it quite ugly to use but that's a separate issue).  It makes
things much easier - e.g. we can use mempool and friends for forward
progress guarantee instead of doing explicit retrying which also can
hide deadlocks quite effectively.

> Well, I wonder if it makes sense *in this case*.  With all of the work
> going into optimizing the flushing, is deferring work to kblockd really
> the best idea?  Tejun, do you know if it has any measurable impact?

I don't think it matters.  First of all, the overhead itself isn't
that big to begin with.  More importantly, the flush optimization is
not about squeezing out the last cpu cycles out of the existing path.
It's about consolidating similar operations and thus increasing
scalability when a storm of fsync's are issued in parallel likely with
a lot of other IOs.  The kicking path won't be used at all on busy
queues (queue won't be empty).

So, I don't think there's anything to worry about here.

Thanks.

-- 
tejun