Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

[Jens Axboe <jens.axboe@oracle.com>]

On Thu, Oct 02 2008, Andrew Morton wrote:
> On Thu, 2 Oct 2008 10:22:13 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Thu, Oct 02 2008, Andrew Morton wrote:
> > > On Thu, 2 Oct 2008 09:45:24 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> > > 
> > > > > So.  Where are these atime updaters getting blocked?
> > > > 
> > > > Behind other IO activity I suppose, since it's marked async. A more
> > > > appropriate fix may be to mark atime updates as sync IO.
> > > 
> > > No, they might be getting blocked at a higher level.
> > > 
> > > An async atime update gets recorded into the current transaction. 
> > > kjournald is working on the committing transaction.  We try to keep
> > > those separated, to prevent user processes from getting blocked behind
> > > kjournald activity.
> > > 
> > > But sometimes that doesn't work (including the place where I knowingly
> > > broke it).  If we can find and fix the offending piece of jbd logic (a
> > > big if) then all is peachy.
> > > 
> > > If the above theory turns out to be true then diddling IO priorities
> > > is but a workaround.
> > 
> > If diddling with io priorities makes a big difference (and Arjan said it
> > does), it's clearly stuck inside the io scheduler waiting to be
> > dispatched. If it was marked sync, it would be going through much
> > faster. As async, it'll get mixed in with other async writeout and that
> > doesn't get a lot of attention in case of sync activity.
> > 
> 
> Maybe.  And maybe marking all journal writeout and all commit activity
> as sync would have the same effect with less downside.
> 
> But it'd be better to not wait on this IO at all, if poss..

Agree, would be much better...

-- 
Jens Axboe