2002-10-30 09:29:19

by Andrew Morton

[permalink] [raw]
Subject: Re: 2.5 merge candidate list, final version. (End of "crunch time"series.)

Jeff Garzik wrote:
>
> Hans Reiser wrote:
>
> > We are going to submit a patch appropriate for inclusion as an
> > experimental FS on Halloween. I hope you will forgive our pushing
> > the limit timewise, it is not by choice, but the algorithms we used to
> > more than double reiserfs V3 performance were, quite frankly, hard to
> > code.
>
> Does your merge change the core code at all? Does it add new syscalls?
>

Their changes are tiny, and sensible. See
http://www.namesys.com/snapshots/2002.10.29/

But I'd like to ask about the status of reiser3 support.

Chris had patches *ages* ago to convert it to use direct-to-BIO for
reads, and writes should be done as well. reiserfs3 is still using
buffer-head-based IO for bulk reads and writes. That's a 25-30% hit
in CPU cost, and all the old ZONE_NORMAL-full-of-buffer_heads
problems.

Any plans to get that work finished off?


2002-10-30 10:09:48

by Nikita Danilov

[permalink] [raw]
Subject: Re: 2.5 merge candidate list, final version. (End of "crunch time"series.)

Andrew Morton writes:
> Jeff Garzik wrote:
> >
> > Hans Reiser wrote:
> >
> > > We are going to submit a patch appropriate for inclusion as an
> > > experimental FS on Halloween. I hope you will forgive our pushing
> > > the limit timewise, it is not by choice, but the algorithms we used to
> > > more than double reiserfs V3 performance were, quite frankly, hard to
> > > code.
> >
> > Does your merge change the core code at all? Does it add new syscalls?
> >
>
> Their changes are tiny, and sensible. See
> http://www.namesys.com/snapshots/2002.10.29/
>
> But I'd like to ask about the status of reiser3 support.
>
> Chris had patches *ages* ago to convert it to use direct-to-BIO for
> reads, and writes should be done as well. reiserfs3 is still using
> buffer-head-based IO for bulk reads and writes. That's a 25-30% hit
> in CPU cost, and all the old ZONE_NORMAL-full-of-buffer_heads
> problems.

Are you talking about buffer_heads_over_limit magic inside vmscan.c? Is
it to avoid deadlock with buffer_head allocation in ->vm_writeback?

>
> Any plans to get that work finished off?

Chris had done great work indeed (plus data logging, plus quotas, plus
ACLs by Jeff Mahoney, etc). Unfortunately we were too busy with reiser4
here lately. Hopefully, a lot of stuff will be merged into reiserfs3.x
after Halloween.

Nikita.

2002-10-30 17:00:56

by Chris Mason

[permalink] [raw]
Subject: Re: 2.5 merge candidate list, final version. (End of "crunch time"series.)

On Wed, 2002-10-30 at 04:35, Andrew Morton wrote:
> Jeff Garzik wrote:
> >
> > Hans Reiser wrote:
> >
> > > We are going to submit a patch appropriate for inclusion as an
> > > experimental FS on Halloween. I hope you will forgive our pushing
> > > the limit timewise, it is not by choice, but the algorithms we used to
> > > more than double reiserfs V3 performance were, quite frankly, hard to
> > > code.
> >
> > Does your merge change the core code at all? Does it add new syscalls?
> >
>
> Their changes are tiny, and sensible. See
> http://www.namesys.com/snapshots/2002.10.29/
>
> But I'd like to ask about the status of reiser3 support.
>
> Chris had patches *ages* ago to convert it to use direct-to-BIO for
> reads, and writes should be done as well. reiserfs3 is still using
> buffer-head-based IO for bulk reads and writes. That's a 25-30% hit
> in CPU cost, and all the old ZONE_NORMAL-full-of-buffer_heads
> problems.
>
> Any plans to get that work finished off?

Very much so, but I wanted it on top of the data journaling stuff to
make porting that easier. But, in the interest in getting something
more stable and faster out the door asap, I'll pull just the
direct-to-BIO stuff out.

-chris