On Fri 30-10-15 14:23:59, KAMEZAWA Hiroyuki wrote:
> On 2015/10/30 0:17, mhocko@xxxxxxxxxx wrote:
[...]
> > @@ -3135,13 +3145,56 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > if (gfp_mask & __GFP_NORETRY)
> > goto noretry;
> >
> > - /* Keep reclaiming pages as long as there is reasonable progress */
> > + /*
> > + * Do not retry high order allocations unless they are __GFP_REPEAT
> > + * and even then do not retry endlessly.
> > + */
> > pages_reclaimed += did_some_progress;
> > - if ((did_some_progress && order <= PAGE_ALLOC_COSTLY_ORDER) ||
> > - ((gfp_mask & __GFP_REPEAT) && pages_reclaimed < (1 << order))) {
> > - /* Wait for some write requests to complete then retry */
> > - wait_iff_congested(ac->preferred_zone, BLK_RW_ASYNC, HZ/50);
> > - goto retry;
> > + if (order > PAGE_ALLOC_COSTLY_ORDER) {
> > + if (!(gfp_mask & __GFP_REPEAT) || pages_reclaimed >= (1<<order))
> > + goto noretry;
> > +
> > + if (did_some_progress)
> > + goto retry;
>
> why directly retry here ?
Because I wanted to preserve the previous logic for GFP_REPEAT as much
as possible here and do an incremental change in the later patch.
[...]
> > @@ -3150,8 +3203,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> > goto got_pg;
> >
> > /* Retry as long as the OOM killer is making progress */
> > - if (did_some_progress)
> > + if (did_some_progress) {
> > + stall_backoff = 0;
> > goto retry;
> > + }
>
> Umm ? I'm sorry that I didn't notice page allocation may fail even
> if order < PAGE_ALLOC_COSTLY_ORDER. I thought old logic ignores
> did_some_progress. It seems a big change.
__alloc_pages_may_oom will set did_some_progress
> So, now, 0-order page allocation may fail in a OOM situation ?
No they don't normally and this patch doesn't change the logic here.
--
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>