On Tue 20-09-22 17:38:30, Zhenhua Huang wrote:
[...]
> > > > Also this patch doesn't really explain why it should work and honestly
> > > > it doesn't really make much sense to me either.
> > > Sorry, my fault. IMO, The reason it should work is, say for this case of
> > > order 3 allocation: we can perform direct reclaim more times as we have only
> > > order 2 pages(which *lowered* by this change) in free_list(8214*16kB (UEC)).
> > > The order requirement which I have lowered is should_reclaim_retry ->
> > > __zone_watermark_ok:
> > > for (o = order; o < MAX_ORDER; o++) {
> > > struct free_area *area = &z->free_area[o];
> > > ...
> > > for (mt = 0; mt < MIGRATE_PCPTYPES; mt++) {
> > > if (!free_area_empty(area, mt))
> > > return true;
> > > }
> > >
> > > Order 2 pages can be more easily met, hence VM has more chance to return
> > > true from should_reclaim_retry.
> >
> > This is a wrong approach to the problem because there is no real
> > guarantee the reclaim round will do anything useful. You should be
> > really looking at the compaction side of the thing.
>
> Thanks Michal for the advice, I'll look at from compaction side also. But I
> have one further question, IMO reclaim(~2GB LRU pages can be reclaimed)
> should be more feasible compared to compaction(already tried with highest
> prio and failed) in this case? Could you please elaborate more...it seems I
> still not fully understand why it's a wrong approach to check from reclaim
> phase.
Mel, has explained a large part I would go with let me just be more
explicit about one part. Memory reclaim is not order aware and that
means that probability of higher order pages are not directly related to
the number of reclaimed pages. You might be lucky and reclaim a THP to
form many order-3 pages or just reclaim those few that would create one
order-3 but all that is very unpredictable and hence we rely on the
compaction. Memory reclaim mostly assists compaction to allow some spare
memory to do the migration.
--
Michal Hocko
SUSE Labs
