Re: [RFC][PATCH] alternative way of calculating inactive_target

Daniel Phillips (phillips@bonn-fries.net)
Thu, 16 Aug 2001 10:55:32 +0200


On August 16, 2001 05:33 am, Roger Larsson wrote:
> Hi,
>
> 1. Two things in this file, first an unrelated issue (but included in the patch)
> global_target in free_shortage shouldn't it be freepages.low?
> Traditionally freepages.high has been when to stop freeing pages.
>
> 2. I have wondered about how inactive_target is calculated.
> This is an alternative approach...
>
> In this alternative approach I use two wrapping counters.
> (memory_clock & memory_clock_rubberband)
>
> memory_clock is incremented only when allocating pages (and it
> is never decremented)

Yes, exactly, did you read my mind? Page units are the natural quantum
of the time base for the whole mm. When we clock all mm events according
to the (__alloc_page << order) timebase then lots of memory spikes are
magically transformed into smooth curves and it becomes immediately
obvious how much scanning we need to do at each instant. Now, warning,
this is a major shift in viewpoint and I'll wager, unwelcome on this side
of the 2.5 split. I'd be happy to work with you doing a skunkworks-type
proof-of-concept though.

> memory_clock_rubberband is calculated to be close to what
> memory_clock should have been for MEMORY_CLOCK_WINDOW seconds
> earlier, using current values and information about how long it was since it
> was updated the last time. This makes it possible to recalculate the target
> more often when pressure is high - and it simplifies kswapd too...

I'll supply a cute, efficient filter that does what you're doing with the
rubberband with a little stronger theoretical basis, as soon as I wake up
again. Or you can look for my earlier "Early flush with bandwidth
estimation" post. (Try to ignore the incorrect volatile handling please.)

BTW, you left out an interesting detail: any performance measurements
you've already done.

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