Messages in this thread | | | Date | Fri, 7 Sep 2001 02:32:38 +0200 | From | Kurt Garloff <> | Subject | Re: page_launder() on 2.4.9/10 issue |
| |
On Thu, Sep 06, 2001 at 04:52:05PM -0300, Rik van Riel wrote: > On Thu, 6 Sep 2001, Daniel Phillips wrote: > > Again, I have to ask, which reads are you interfering with? Ones that > > haven't happened yet? Remember, the disk is idle. So *at worst* you are > > going to get one extra seek before getting hit with the tidal wave of reads > > you seem to be worried about. This simply isn't significant. > > > > I've tested this, I know early writeout under light load is a win. > > Other people have tested this too, and light writeout of > small blocks destroys the performance of a heavy read > load.
Then just don't take two hard limits, but make an easy mathematical function of time and blocks to write (monotonic and with positive slope in both) and start to write all blocks once we execced a certain limit. So, if you produce very few dirty inactive pages, it'll only happen every thirty seconds, e.g., at moderate loads, it may happen every 4 seconds and at higher loads it may even happen a couple of times per second. Think of a function like t + t*b + b, with appropriate scaling, so we reach the threshold either after a long time alone, because of many dirty inactive pages alone or because a combination of both. Tuning should be such that under normal workloads, the combination of time times pages should be the most significant term.
(The chance that you run into memory pressure because of too many dirty pages this way is lower than before, but if it happens, you can adjust your function or the threshold too flush more pages.)
If you are very concerned about read performance suffering from this, you may even monitor reads and adjust the threshold according to read load. (Or just make your function include this variable with a negative slope.) I believe it won't be necessary though.
Regards, -- Kurt Garloff <garloff@suse.de> Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, DE SCSI, Security [unhandled content-type:application/pgp-signature] | |