Messages in this thread |  | | Date | Mon, 18 Sep 2000 11:42:04 +0100 (BST) | From | James Sutherland <> | Subject | Re: /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/
|  |