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


Groups > linux.kernel > #1281841

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

From Mel Gorman <mgorman@techsingularity.net>
Newsgroups linux.kernel
Subject Re: [lkp] [mm, page_alloc] d0164adc89: -100.0% fsmark.app_overhead
Date 2015-12-02 15:10 +0100
Message-ID <qBggB-8db-73@gated-at.bofh.it> (permalink)
References (2 earlier) <qzfRD-4qq-1@gated-at.bofh.it> <qzo8y-1rQ-25@gated-at.bofh.it> <qAmen-5NT-37@gated-at.bofh.it> <qBdsn-6oc-29@gated-at.bofh.it> <qBeoq-6Z9-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Dec 02, 2015 at 01:00:46PM +0100, Michal Hocko wrote:
> On Wed 02-12-15 11:00:09, Mel Gorman wrote:
> > On Mon, Nov 30, 2015 at 10:14:24AM +0800, Huang, Ying wrote:
> > > > There is no reference to OOM possibility in the email that I can see. Can
> > > > you give examples of the OOM messages that shows the problem sites? It was
> > > > suspected that there may be some callers that were accidentally depending
> > > > on access to emergency reserves. If so, either they need to be fixed (if
> > > > the case is extremely rare) or a small reserve will have to be created
> > > > for callers that are not high priority but still cannot reclaim.
> > > >
> > > > Note that I'm travelling a lot over the next two weeks so I'll be slow to
> > > > respond but I will get to it.
> > > 
> > > Here is the kernel log,  the full dmesg is attached too.  The OOM
> > > occurs during fsmark testing.
> > > 
> > > Best Regards,
> > > Huang, Ying
> > > 
> > > [   31.453514] kworker/u4:0: page allocation failure: order:0, mode:0x2200000
> > > [   31.463570] CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.3.0-08056-gd0164ad #1
> > > [   31.466115] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Debian-1.8.2-1 04/01/2014
> > > [   31.477146] Workqueue: writeback wb_workfn (flush-253:0)
> > > [   31.481450]  0000000000000000 ffff880035ac75e8 ffffffff8140a142 0000000002200000
> > > [   31.492582]  ffff880035ac7670 ffffffff8117117b ffff880037586b28 ffff880000000040
> > > [   31.507631]  ffff88003523b270 0000000000000040 ffff880035abc800 ffffffff00000000
> > 
> > This is an allocation failure and is not a triggering of the OOM killer so
> > the severity is reduced but it still looks like a bug in the driver. Looking
> > at the history and the discussion, it appears to me that __GFP_HIGH was
> > cleared from the allocation site by accident. I strongly suspect that Will
> > Deacon thought __GFP_HIGH was related to highmem instead of being related
> > to high priority.  Will, can you review the following patch please? Ying,
> > can you test please?
> 
> I have posted basically the same patch
> http://lkml.kernel.org/r/1448980369-27130-1-git-send-email-mhocko@kernel.org
> 

Sorry. I missed that while playing catch-up and I wasn't on the cc. I'll
drop this patch now. Thanks for catching it.

> 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. Such callers are normally expected
to be able to recover gracefully and probably should specify _GFP_NOWARN.
kswapd would have woken up as normal but the free pages were below the
min watermark so there was a brief failure.

-- 
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 | NextPrevious 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