Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 2 Oct 2008 17:06:46 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Fri, 3 Oct 2008 09:58:49 +1000
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > On Thu, Oct 02, 2008 at 02:37:13PM -0700, Andrew Morton wrote:
> > > On Thu, 2 Oct 2008 21:22:23 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> > > > Can we agree on this patch?
> > > 
> > > This change will cause _all_ kjournald writeout to have elevated
> > > priority.  The majority of that writeout (in data=ordered mode) is file
> > > data, which we didn't intend to change.
> > > 
> > > The risk here is that this will *worsen* latency for plain old read(),
> > > because now kjournald writeout will be favoured.
> > > 
> > > There is in fact a good argument for _reducing_ kjournald's IO
> > > priority, not increasing it!
> > > 
> > > A better approach might be to mark the relevant buffers/bios as needing
> > > higher priority at submit_bh() time (if that's possible).  At least
> > > that way we don't accidentally elevate the priority of the bulk data.
> > 
> > You can do that for submit_bio() by calling bio_set_prio() before
> > submision - I did that for elevating only the XFS journal I/O.
> > submit_bh() doesn't have any way of passing a priority through to it
> > right now...
> 
> Yup.  There are plenty of spare bits in buffer_head.b_state. 
> set_buffer_kludge()?
> 

And if we do decide to run set_buffer_kludge() against these blocks
then it should be done at the time when they are marked dirty, when JBD
refiles them for checkpoint writeback.

This is because kjournald isn't the only process which writes these
buffers.  Pretty often (usually?) it is pdflush.  The increased IO
prioritisation is a property of the buffer, not of the task which
submits it for IO.  I suspect.