On Fri 26-02-16 18:27:16, Hillf Danton wrote:
> >>
> > > --- a/mm/page_alloc.c Thu Feb 25 15:43:18 2016
> > > +++ b/mm/page_alloc.c Fri Feb 26 15:18:55 2016
> > > @@ -3113,6 +3113,8 @@ should_reclaim_retry(gfp_t gfp_mask, uns
> > > struct zone *zone;
> > > struct zoneref *z;
> > >
> > > + if (order <= PAGE_ALLOC_COSTLY_ORDER)
> > > + return true;
> >
> > This is defeating the whole purpose of the rework - to behave
> > deterministically. You have just disabled the oom killer completely.
> > This is not the way to go
> >
> Then in another direction, below is what I can do.
>
> thanks
> Hillf
> --- a/mm/page_alloc.c Thu Feb 25 15:43:18 2016
> +++ b/mm/page_alloc.c Fri Feb 26 18:14:59 2016
> @@ -3366,8 +3366,11 @@ retry:
> no_progress_loops++;
>
> if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
> - did_some_progress > 0, no_progress_loops))
> + did_some_progress > 0, no_progress_loops)) {
> + /* Burn more cycles if any zone seems to satisfy our request */
> + no_progress_loops /= 2;
No, I do not think this makes any sense. If we need more retry loops
then we can do it by increasing MAX_RECLAIM_RETRIES.
> goto retry;
> + }
>
> /* Reclaim has failed us, start killing things */
> page = __alloc_pages_may_oom(gfp_mask, order, ac, &did_some_progress);
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>