linux-kernel - Re: [PATCH] Give kjournald a IOPRIO_CLASS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 2 Oct 2008 17:20:23 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	david@...morbit.com, jens.axboe@...cle.com, arjan@...radead.org,
	andi@...stfloor.org, linux-kernel@...r.kernel.org,
	alan@...rguk.ukuu.org.uk
Subject: Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

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

> On Fri, 3 Oct 2008 09:58:49 +1000
> Dave Chinner <david@...morbit.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@...cle.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/