Messages in this thread | | | Date | Wed, 1 Oct 2008 23:55:01 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH] Give kjournald a IOPRIO_CLASS_RT io priority |
| |
On Thu, 2 Oct 2008 08:27:37 +0200 Jens Axboe <jens.axboe@oracle.com> wrote:
> On Wed, Oct 01 2008, Andrew Morton wrote: > > On Wed, 1 Oct 2008 20:00:34 -0700 Arjan van de Ven <arjan@infradead.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?
| |