lkml.org 
[lkml]   [2002]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] 2.4.x write barriers (updated for ext3)
    Date
    From
    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.

    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.

    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?

    James


    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 13:24    [W:3.264 / U:0.368 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site