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]

Message-ID: <20081002074523.GW19428@kernel.dk>
Date:	Thu, 2 Oct 2008 09:45:24 +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 Wed, Oct 01 2008, Andrew Morton wrote:
> On Thu, 2 Oct 2008 08:27:37 +0200 Jens Axboe <jens.axboe@...cle.com> wrote:
> 
> > On Wed, Oct 01 2008, Andrew Morton wrote:
> > > On Wed, 1 Oct 2008 20:00:34 -0700 Arjan van de Ven <arjan@...radead.org> wrote:
> > > 
> > > > Subject: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority
> > > 
> > > You proposed this a while back and it didn't happen and I forget
> > > why and the changelog doesn't mention any of that?
> > 
> > I think you called for benchmark results, which I don't think happened.
> > The patch definitely makes sense, so we should just make sure that we
> > don't regress elsewhere. Honestly, I'd be surprised if we did...
> 
> Now I think about it, didn't the earlier patch tweak CPU priority and
> not IO priority?  I forget.  <kicks the changelog again>
> 
> > How about I just toss it into the 2.6.28 testing mix, plenty of time for
> > testing and such?
> 
> Many performance regressions don't get noticed for six or twelve
> months, by which time everyone is suffering from them (see
> kernel/sched.c).
> 
> kjournald does huge amounts of not-terribly-important writeback.  One
> obvious risk is that by making all that bulk writeback high-priority,
> read-latency-sensitive applications might suffer latency spikes.
> 
> 
> 
> Now, kjournald is _supposed_ to be mostly asynchronous wrt foreground
> operations.  And once upon a time (seven years ago) it mostly was.  But
> there was some horrid race which I ended up fixing by introducing one
> point where synchronous userspace actions had to block behind kjournald
> activity.  I spent quite some time on it but couldn't come up with
> anything better.  It had fairly bad effects on some workloads.
> 
> I've forgotten where that code is now, but I don't think it was ever
> revisited.  It should be.
> 
> 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.

Once upon a time I actually did start xxxing meta data IO from the file
system, in ext3. That was mainly for blktrace so we could inspect what
data was what at the trace end, but if we had full coverage (or better,
at least), we could use that to bump priority as well. Probably the
priority should be left at the default, but the IO should be upgraded to
SYNC instead. That'll ensure that it goes out fairly quickly (like other
IO at the same class), but not get preferential treatment apart from
that. Seems like the right thing to do.

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