On Monday, March 04, 2002 11:35:24 AM -0600 James Bottomley <James.Bottomley@steeleye.com> wrote:
> sct@redhat.com said:
>> Generally, that may be true but it's irrelevant. Internally, the fs
>> may keep transactions as independent, but as soon as IO is scheduled,
>> those transactions become serialised. Given that pure sequential IO
>> is so much more efficient than random IO, we usually expect
>> performance to be improved, not degraded, by such serialisation.
>
> This is the part I'm struggling with. Even without error handling and certain
> other changes that would have to be made to give guaranteed integrity to the
> tag ordering, Chris' patch is a very reasonable experimental model of how an
> optimal system for implementing write barriers via ordered tags would work;
> yet when he benchmarks, he sees a performance decrease.
>
Actually most tests I've done show no change at all. So far, only
lots of O_SYNC writes stress the log enough to show a performance
difference, about 10% faster with tags on.
> I can dismiss his results as being due to firmware problems with his drives
> making them behave non-optimally for ordered tags, but I really would like to
> see evidence that someone somewhere acutally sees a performance boost with
> Chris' patch.
So would I ;-)
>
> Have there been any published comparisons of a write barrier implementation
> verses something like the McKusick soft update idea, or even just
> multi-threaded back end completion of the transactions?
Sorry, what do you mean by multi-threaded back end completion of the
transaction?
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:34 EST