Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1281871

Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead

Show all headers | View raw

On Wed, Dec 02, 2015 at 03:15:29PM +0100, Michal Hocko wrote:
> > > I didn't mention this allocation failure because I am not sure it is
> > > really related.
> > > 
> > 
> > I'm fairly sure it is. The failure is an allocation site that cannot
> > sleep but did not specify __GFP_HIGH.
> 
> yeah but this was the case even before your patch. As the caller used
> GFP_ATOMIC then it got __GFP_ATOMIC after your patch so it still
> managed to do ALLOC_HARDER. I would agree if this was an explicit
> GFP_NOWAIT. Unless I am missing something your patch hasn't changed the
> behavior for this particular allocation.
> 

You're right. I think it's this hunk that is the problem.

@@ -1186,7 +1186,7 @@ static struct request *blk_mq_map_request(struct
request_queue *q,
                ctx = blk_mq_get_ctx(q);
                hctx = q->mq_ops->map_queue(q, ctx->cpu);
                blk_mq_set_alloc_data(&alloc_data, q,
-                               __GFP_WAIT|GFP_ATOMIC, false, ctx, hctx);
+                               __GFP_WAIT|__GFP_HIGH, false, ctx, hctx);
                rq = __blk_mq_alloc_request(&alloc_data, rw);
                ctx = alloc_data.ctx;
                hctx = alloc_data.hctx;

This specific path at this patch is not waking kswapd any more when it
should. A series of allocations there could hit the watermarks and never wake
kswapd and then be followed by an atomic allocation failure that woke kswapd.

This bug gets fixed later by the commit 71baba4b92dc ("mm, page_alloc:
rename __GFP_WAIT to __GFP_RECLAIM") so it's not a bug in the current
kernel. However, it happens to break bisection and would be caught if each
individual commit was tested.

Your __GFP_HIGH patch is still fine although not the direct fix for this
specific problem. Commit 71baba4b92dc is.

Ying, does the page allocation failure messages happen when the whole
series is applied? i.e. is 4.4-rc3 ok?

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

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Mel Gorman <mgorman@techsingularity.net> - 2015-12-02 12:10 +0100
  Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Michal Hocko <mhocko@kernel.org> - 2015-12-02 13:10 +0100
    Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Mel Gorman <mgorman@techsingularity.net> - 2015-12-02 15:10 +0100
      Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Michal Hocko <mhocko@kernel.org> - 2015-12-02 15:20 +0100
        Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Mel Gorman <mgorman@techsingularity.net> - 2015-12-02 15:50 +0100
          Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead "Huang\, Ying" <ying.huang@linux.intel.com> - 2015-12-03 09:50 +0100
            Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Mel Gorman <mgorman@techsingularity.net> - 2015-12-03 11:20 +0100
              Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead "Huang\, Ying" <ying.huang@linux.intel.com> - 2015-12-04 03:00 +0100
                Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead Michal Hocko <mhocko@kernel.org> - 2015-12-07 17:20 +0100

csiph-web