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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:18 EST