From: Mingming Cao <cmm@us.ibm.com>
The ext3 reservation patches changed the non-reservation block allocation
path. The changes does not cause the time regression on untar.sh, but
changed the disk layout. So later when run read.sh or cp.sh, it
sequentially caused the regression I saw.
There is a performance optimization code previously presented in mainline
kernel has removed, I thought it might not appropriate for the reservation
case. It turns out it hurt the non-reservation case and not optimized for
the reservation case. There are another changes that are considered for
reservation turned on case but not optimized for the non-reservation
change.
I have tested the patch against 265-mm6 on my 8way, no regression there
(with reservation and with no reservation, compare with 2.6.5).
---
25-akpm/fs/ext3/balloc.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletion(-)
diff -puN fs/ext3/balloc.c~ext3-reservation-regression-fix fs/ext3/balloc.c
--- 25/fs/ext3/balloc.c~ext3-reservation-regression-fix 2004-04-20 23:43:10.215216408 -0700
+++ 25-akpm/fs/ext3/balloc.c 2004-04-20 23:44:25.944703776 -0700
@@ -456,7 +456,7 @@ find_next_usable_block(int start, struct
r = memscan(p, 0, (maxblocks - here + 7) >> 3);
next = (r - ((char *)bh->b_data)) << 3;
- if (next < maxblocks && ext3_test_allocatable(next, bh))
+ if (next < maxblocks && next >= start && ext3_test_allocatable(next, bh))
return next;
/*
@@ -538,6 +538,15 @@ repeat:
goal = find_next_usable_block(start, bitmap_bh, end);
if (goal < 0)
goto fail_access;
+ if (!my_rsv) {
+ int i;
+
+ for (i = 0; i < 7 && goal > start &&
+ ext3_test_allocatable(goal - 1,
+ bitmap_bh);
+ i++, goal--)
+ ;
+ }
}
start = goal;
_