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

[Linus Torvalds]

On Tue, 7 Aug 2001, Linus Torvalds wrote:
>
> The current patch "zone_free_plenty()" logic also happens to be just at
> the corner of what __alloc_pages() thinks is good, so the anti-hysteresis
> doesn't actually end up working in that sense - we end up bouncing around
> that magic "pages_high" value.

The same, it seems, is true of "total_free_shortage()", and the zone
"pages_low" corner.

We start up kswapd when the free count shrinks below "pages_low", so we
should keep kswapd running for longer than that, and I think your version
of "zone_free_shortage()" was thus the better one - using pages_high as
the point where we no longer think there is a shortage.

We should really document the ranges clearly. Right now (with these
changes), the ranges would be (with users in parenthesis):

 inactive (free + inactive_clean + inactive_dirty):

	low water mark: zone->pages_high	(zone_inactive_shortage, total_inactive_shortage)
	high water mark: zone->size / 3		(zone_inactive_plenty)

 free (free + inactive_clean):

	low water mark: zone->pages_high	(__alloc_pages, zone_free_shortage)
	high water mark: zone->pages_high*2	(zone_free_plenty)

 reclaim (free):

	low water mark: zone->pages_min		(__alloc_pages)
	high water mark: zone->pages_low	(kreclaimd)

and they now sem to (a) always have a nice hysteresis region (ie low is
clearly smaller than high, once the free+inactive_clean case has been
fixed) and (b) the different low/high water mark users seem to agree.

Looks reasonably sane to me. Can anybody find a case where we use
conflicting low/high watermarks?

		Linus