Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

From: Jens Axboe
Date: Thu Oct 02 2008 - 04:47:18 EST


On Thu, Oct 02 2008, Andrew Morton wrote:
> On Thu, 2 Oct 2008 10:22:13 +0200 Jens Axboe <jens.axboe@xxxxxxxxxx> wrote:
>
> > On Thu, Oct 02 2008, Andrew Morton wrote:
> > > On Thu, 2 Oct 2008 09:45:24 +0200 Jens Axboe <jens.axboe@xxxxxxxxxx> 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

--
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/