Hans Reiser wrote:
> "Vladimir V. Saveliev" wrote:
> >
> > Dirk Haage wrote:
> >
> > > Am 03 Jul 2001 21:18:34 +0400 schrieb Nikita Danilov:
> > > [some performance tests]
> > > > [Table skipped.]
> > > >
> > > > ReiserFS is extremely fast with simple file system operations; as soon as
>parallel
> > > > accesses of several processes takes place, the performance breaks in
> > > > however clearly.
> > >
> > > So the real question ist, why does ReiserFS-Performance drop if parallel accesses
> > > happen? Is there any explanation for this?
> > >
> >
> > Probably due to "an algorithm" of repeats reiserfs uses to perform parallel tree
> > updates. The more parallel acccess work together - the more they have to repeat -
>the
> > more performance falls down.
> >
> > Thanks,
> > vs
>
> More likely, reiserfs schedules more often than ext2 (during accesses to formatted
>nodes), and
> scheduling reduces serialization, and greater serialization improves parallel
>accesses on a single
> disk drive (by huge amounts, as you can see if you run a few benchmarks).
>
> The parallel updates explanation seems unlikely to me, because find + wc does not
>cause balancing.
>
> Reading indirect items is expensive, because we do no readahead on them, and as a
>result other IOs
> have an opportunity to insert themselves and move the head away.
>
> We need not just to have indirect items that precede the blocks that they point to,
>but also to keep
> other things from grabbing our disk head while we wait for the indirect item to tell
>us to read the
> block immediately after it.
>
> Perhaps giving Linux a real elevator algorithm, plus doing readahead when accessing
>indirect items
> that are located right after the block just read?
>
> Thoughts on how we might solve this?
Is there already a "smart readahead" that does readahead on the logical and not
physical layer? E.g. if
there a file which is fragmented, readahead should not read beyond a fragment, but it
should read the
next fragment ahead. The same applies for directories.
Maybe there should be a parameter to regulate when reiserfs schedules under load. For
example, this
could be a time measured in microseconds or nanoseconds. When reiserfs calls
conditional_schedule(), it
calls schedule(), and sets the time which is the lower limit of the time when the next
schedule() should
be called by conditional_schedule() by using the current time and adding the delay. On
the next call to
schedule(), the delay may not be exceeded. In this case, conditional_schedule()
returns instead of
calling schedule().
As long as this does not lead to spinning, I think this is a practical solution.
Another solution can be to use the "logical read ahead" by predicting what blocks will
be likely to be
read next, and giving this information to the elevator and then calling schedule(). If
it is a good
elevator, it will merge the request of the parallel processes into one large optimized
elevator walk.
The time schedule() returns, the data needed can already be in memory.
Maybe there should also be a kind of "good prediction feedback". If the read ahead
prediction is good,
the number of blocks used for prediction should be enlarged. If it is bad, the number
of predicted
blocks should be shrinked. This feedback algorithm would make bulk transfers faster
while random
accesses do not consume unneccessary readahead.
>
>
> Hans
Xu�n.
