Re: [PATCH] ide write barriers

[Jens Axboe <axboe@suse.de>]

On Wed, Feb 05 2003, Marc-Christian Petersen wrote:
> On Wednesday 05 February 2003 17:33, Jens Axboe wrote:
> 
> Hi Jens,
> 
> > Sure, I had that one already. BTW, I discovered that the default io
> thank you :)
> 
> > scheduler forgets to honor the cmd_flags, it's supposed to break like
> > the noop does (see very first hunk in very first file). Must have
> > removed that by mistake some time ago... This applies both to the
> > 2.4.21-pre4 patch posted and this one.
> well, I am impressed, really!
> 
> As you described in the patch:
> 
> + *   For journalled file systems, doing ordered writes on a commit
> + *   block instead of explicitly doing wait_on_buffer (which is bad
> + *   for performance) can be a big win. Block drivers supporting this
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> I don't have benchmarks handy yet but as far as I can _feel_, this is
> a _MUST_ (I repeat: a _MUST_ for 2.4.21). And I am very good in
> feeling slowdowns for interactivity :)
> 
> I am running it for quite some hours now with 2.4.20. Well, maybe the 
> nr_requests = 16 and read/write passovers changes in the elevator code give 
> us more smoothness than w/o but in my theoretical mind, this should drop 
> throughput. I also noticed, these changes aren't in your 2.4.21 patch. Can 
> you explain why it is in 2.4.20 patch or why it isn't in 2.4.21 patch ? :)

There are not in the 2.4.21-pre patch, because the 2.4.20 got mixed with
another patch. The limiting of number of queue requests is a different
patch, and it's quite likely it will provide better interactiveness for
you. But it will also considerably drop throughput, depends on the work
load whether that's the case or not.

I don't think ext3 will show a performance boost with the supplied
patch, but the stuff for reiser that Christ did definitely will.

-- 
Jens Axboe