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 10:46:49 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority

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

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