xfs
[Top] [All Lists]

Re: performance degraded 2.4.8 -> 2.4.9?

To: Andi Kleen <ak@xxxxxxx>
Subject: Re: performance degraded 2.4.8 -> 2.4.9?
From: Peter Wächtler <pwaechtler@xxxxxxxxxxxxx>
Date: Thu, 15 Nov 2001 10:31:18 +0100
Cc: Steve Lord <lord@xxxxxxx>, linux-xfs@xxxxxxxxxxx
Organization: LOEWE. Hannover
References: <3BF1A6F2.273B49C4@xxxxxxxx> <1005696924.21227.4.camel@UberGeek> <3BF27ACB.B744479A@xxxxxxxx> <1005752233.25611.2.camel@xxxxxxxxxxxxxxxxxxxx> <20011114165901.A28687@xxxxxxxxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
Andi Kleen wrote:
> 
> > Its a myth! We do not have changes all over the kernel, and we
> > definitely do not have any changes in the block layer. The last
> 
> Hmm, last time I checked you had some support for delayed buffers there...
> Not that I think that particular it is very intrusive, but I had some
> problems with it in the past porting it to a custom kernel.
> 
> -Andi

in xfs-2.4.14-all.bz2:

diff -urN 2.4.14-pristine/fs/buffer.c xfs-2.4.14/fs/buffer.c
--- 2.4.14-pristine/fs/buffer.c Tue Nov  6 12:06:47 2001
+++ xfs-2.4.14/fs/buffer.c      Fri Nov  9 15:12:18 2001
[...]
+static inline int
+write_buffer_locked(struct buffer_head *bh, int wait)
+{
+       int     ret;
+
+       if (!buffer_delay(bh)) {
+               submit_bh(WRITE, bh);
+               return 1;
+       } else {
+               clear_bit(BH_Lock, &bh->b_state);
+               smp_mb__after_clear_bit();
+               ret = _write_buffer(bh, wait);
+               if ((ret == 0) && waitqueue_active(&bh->b_wait))
+                       wake_up(&bh->b_wait);
+       }
+}
+
+

@@ -2361,7 +2426,7 @@
                get_bh(bh);
                set_bit(BH_launder, &bh->b_state);
                bh->b_end_io = end_buffer_io_sync;
-               submit_bh(WRITE, bh);
+               write_buffer_locked(bh, 0);
                tryagain = 0;
        } while ((bh = bh->b_this_page) != head);


a cosmetic error: this function can return unpredictable values 
(missing "return ret;" at the end).
But the only caller ignores the return code anyway.


<Prev in Thread] Current Thread [Next in Thread>