ext3 performs its own writeback alongside the core kernel's writeback
decisions, so that complicates things.
> Test workload was an
> inbound (from the point of view of the system under test) FTP transfer of a
> 600 MB iso image. All test runs were from a clean boot with all unnecessary
> services shut down.
>
> Results (average of 4 runs):
>
> 2.5.31-akpm: 2m 43s
> 2.5.31: 2m 33s
> 2.4.19: 2m 18s
yes. For this workload (10 mbyte/sec ftp transfer onto a >20 meg/sec
disk) the application should never block on IO - all writeback should
happen via pdflush.
2.4 starts background writeback at 30% dirty and synchronous writeback
at 60% dirty.
2.5 starts background writeback at 40% dirty and synchronous writeback
at 50% dirty.
You can make 2.5 use the 2.4 settings with
cd /proc/sys/vm
echo 30 > dirty_background_ratio
echo 60 > dirty_async_ratio
echo 70 > dirty_sync_ratio
and I expect you'll find that fixes it up. Setting dirty_background_ratio
to 10% will make it even better. But it will hurt dbench numbers at
certain client counts, which is a national emergency.
Sigh. I don't know what the right numbers are. There aren't any; that's
the problem with magic numbers. That part of the kernel is making writeback
and throttling decisions in total ignorance of the overall state of
the system.
Worst comes to worst, we can set the 2.5 knobs at the same level as the
2.4 ones, but I'd rather prefer that we can some up with something dynamic.
In fact, I'd be inclined to set the background ratio much lower than
2.4, and to hell with dbench. Because the lower level is better for
real programs, as you've observed.
Care to tune and retest?
-
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/