Re: [PATCH v4] page_alloc: consider highatomic reserve in watermark fast

[Michal Hocko <mhocko@kernel.org>]

On Mon 22-06-20 11:04:39, Mel Gorman wrote:
> On Mon, Jun 22, 2020 at 06:40:20PM +0900, ????????? wrote:
> > >But more importantly, I have hard time to follow why we need both
> > >zone_watermark_fast and zone_watermark_ok now. They should be
> > >essentially the same for anything but order == 0. For order 0 the
> > >only difference between the two is that zone_watermark_ok checks for
> > >ALLOC_HIGH resp ALLOC_HARDER, ALLOC_OOM. So what is exactly fast about
> > >the former and why do we need it these days?
> > > 
> > 
> > I think the author, Mel, may ansewr. But I think the wmark_fast may
> > fast by 1) not checking more condition about wmark and 2) using inline
> > rather than function. According to description on commit 48ee5f3696f6,
> > it seems to bring about 4% improvement.
> > 
> 
> The original intent was that watermark checks were expensive as some of the
> calculations are only necessary when a zone is relatively low on memory
> and the check does not always have to be 100% accurate. This is probably
> still true given that __zone_watermark_ok() makes a number of calculations
> depending on alloc flags even if a zone is almost completely free.

OK, so we are talking about 
	if (alloc_flags & ALLOC_HIGH)
		min -= min / 2;

	if (unlikely((alloc_flags & (ALLOC_HARDER|ALLOC_OOM))) {
		/*
		 * OOM victims can try even harder than normal ALLOC_HARDER
		 * users on the grounds that it's definitely going to be in
		 * the exit path shortly and free memory. Any allocation it
		 * makes during the free path will be small and short-lived.
		 */
		if (alloc_flags & ALLOC_OOM)
			min -= min / 2;
		else
			min -= min / 4;
	}

Is this something even measurable and something that would justify a
complex code? If we really want to keep it even after these changes
which are making the two closer in the cost then can we have it
documented at least?
-- 
Michal Hocko
SUSE Labs