Messages in this thread | | | Date | Mon, 12 Aug 2002 20:26:03 -0400 | From | Adam Kropelin <> | Subject | Re: [patch 1/21] random fixes |
| |
On Sun, Aug 11, 2002 at 09:58:22PM -0700, Andrew Morton wrote: > ext3 performs its own writeback alongside the core kernel's writeback > decisions, so that complicates things.
I ran the test after mounting the partition as ext2 and saw a slight decrease in performance (7-10 seconds over the duration of the test), but I did not have time to run more than once so this could be a fluke. In general, the `vmstat 1` output looked the same to me.
> > 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.
> 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
These settings bring -akpm in line with stock 2.5.31, but they are both still slower than 2.4.19 (which itself could do better, I think).
> 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
No real change at 10%. It's consistently a second or two faster than -akpm is at 30%, but not a drastic change.
> 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.
It certainly seems something is amiss. If we could actually manage to keep the disk busy (and this is a fairly slow disk), we'd do wonderfully. But with a 2-3 second pause every 4-5 seconds, we're transferring data barely 50% of the time. (Yes, the pause is long enough the disk activity LED actually goes out.) The short-term average transfer rate over the FTP connection is very respectable for older hardware: 7-8 MB/s. But with the stalls, the overall throughput is just over 4 MB/s.
> 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?
Absolutely. I'll try whatever ideas/patches you want to throw at me.
BTW, full `vmstat 1` logs are available for all these tests if you want them.
--Adam
- 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/
| |