Re: [PATCH] total_free_shortage() using zone_free_shortage()

[Linus Torvalds]

On Wed, 8 Aug 2001, Marcelo Tosatti wrote:
>
> I'll check if I can do happen in practice with the "pages_high*2" changes.

I have convinced myself (and probably confused everybody else) that the
right thing is to use "pages_high*2" for the zone_free_plenty() case, and
to use "pages_low" for the "zone_free_shortage()" case.

Basically, with the plenty changes, we have more than high/low water
marks. We have

 - low water: this is when allocators start trying to free and/or wake up
   others to free. This is a per-zone thing.

	zone_free_shortage: zone_free < zone->pages_low

 - high water: this is when allocators are happy and we can stop
   freeing "on average". This is a global thing.

	global_free_shortage: global_free < freepages.high

 - "plenty": this is when the freeing logic starts to decide that even if
   there's a page to be free'd (and we want to continue to free due to
   _other_ zones being low), we're "over the top" as far as this one is
   concerned. This is per-zone again.

	zone_free_plenty: zone_free > zone->pages_high*2

And note how the "global average" should always be in between the sum of
the local minima and maxima - which is true above, as freepages.high =
sum(zone->pages_high).

Just to take another example: we have the exact same situation on the
inactive page targets too:

 - low water: zone->pages_high (per-zone)
 - high water: freepages.high + inactive_target (global)
 - "plenty": zone->size / 3 (per-zone)

and for inactive pages we've had this for a while now.. Again, the global
high water mark is in between the local low/max marks.

I'm happy.

Just to make sure we're on the same page and are going to test the same
things ;)

		Linus