lkml.org 
[lkml]   [2016]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/3] OOM detection rework v4
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

\
 
 \ /
  Last update: 2016-02-26 15:21    [W:0.208 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site