lkml.org 
[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /proc/sys/vm/freepages not writable.
On Sun, 17 Sep 2000, Evan Jeffrey wrote:

>
> > > 1. The inactive_target is 1 second worth of allocations, minus
> > > the amount of frees in 1 second, averaged over a minute
> >
> > So it cannot take load bursts. That's ok for a default, but for special loads
> > it would be good if there was a way for the administrator to overwrite that,
> > similar to the old freepages.
>
> How about taking a decaying average (loadavg style) of the peak
> allocation-free rate on a minute-by-minute basis. Then make the
> number of seconds at that rate to use as the inactive_target a tunable
> parameter. That way, a user could, if necessary, tune based on their
> expected type of load (length of load bursts), and the alg. would tune
> to the load level (height of those bursts). For a consistent load,
> peak rate ~= avg. rate, and this decays to the current behavior,
> except that the "1 second of allocations" is tunable.

If we take the load avg analogy a bit further, we should be able to spot
trends, at least to a limited extent: if the short term allocation rate is
higher than the long term, there's an increasing trend, so we should
probably try to keep more.

Tracking something like the last minute - as presently - but divided into
"last 30 seconds" and "previous 30 seconds" would probably help here; take
the first minus the second (rate of "acceleration") and add to the first,
and divide by 30. Use 32 for speed, perhaps, making it:

((a << 1) - b) >> 5

Should be an easy enough change, and a slightly better metric than just a
simple average?

> I haven't actually looked at the code, so I don't know how easy/hard
> this is to implement, and while it does reintroduce a tuning
> parameter, it should be needed less often, and has a much more
> user-meaningful value (burst length) than # of free pages to keep
> handy, which depends on the code, and could change between versions.

With a reasonable "guess" based on recent history, we should be able to
keep enough around to handle most circumstances.


James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.069 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site