Messages in this thread | | | Date | Mon, 04 Mar 2002 12:48:44 -0500 | From | Chris Mason <> | Subject | Re: [PATCH] 2.4.x write barriers (updated for ext3) |
| |
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/
| |