Re: [PATCH 6/6] mm: page_alloc: Reduce cost of the fair zone allocation policy

[Vlastimil Babka]

On 08/11/2014 02:12 PM, Mel Gorman wrote:
> On Fri, Aug 08, 2014 at 05:27:15PM +0200, Vlastimil Babka wrote:
> > On 07/09/2014 10:13 AM, Mel Gorman wrote:
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1604,6 +1604,9 @@ again:
> > >   	}
> > >
> > >   	__mod_zone_page_state(zone, NR_ALLOC_BATCH, -(1 << order));
> >
> > This can underflow zero, right?
>
> Yes, because of per-cpu accounting drift.

I meant mainly because of order > 0.

> > > +	if (zone_page_state(zone, NR_ALLOC_BATCH) == 0 &&
> >
> > AFAICS, zone_page_state will correct negative values to zero only for
> > CONFIG_SMP. Won't this check be broken on !CONFIG_SMP?
>
> On !CONFIG_SMP how can there be per-cpu accounting drift that would make
> that counter negative?

Well original code used "if (zone_page_state(zone, NR_ALLOC_BATCH) <= 
0)" elsewhere, that you are replacing with zone_is_fair_depleted check. 
I assumed it's because it can get negative due to order > 0. I might 
have not looked thoroughly enough but it seems to me there's nothing 
that would prevent it, such as skipping a zone because its remaining 
batch is lower than 1 << order.
So I think the check should be "<= 0" to be safe.

Vlastimil


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