lkml.org 
[lkml]   [2001]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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]
\
 
 \ /
  Last update: 2005-03-22 13:02    [W:0.158 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site