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

[Marcelo Tosatti]

On Tue, 7 Aug 2001, Linus Torvalds wrote:

> 
> 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?

No, I think its ok.

But we still allow a certain zone from staying in a critical shortage for
a long period of time. It can (and used to, before the zoned approach
code) trigger OOM deadlocks.

I'll check if I can do happen in practice with the "pages_high*2" changes.