lkml.org 
[lkml]   [2015]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG REPORT] OOM Killer is invoked while the system still has much memory
On Tue 14-07-15 17:14:40, Xishi Qiu wrote:
> On 2015/7/14 17:00, Michal Hocko wrote:
>
> > On Tue 14-07-15 16:42:16, Xishi Qiu wrote:
> >> On 2015/7/14 16:15, Michal Hocko wrote:
> >>
> >>> On Tue 14-07-15 07:11:34, Xuzhichuang wrote:
> > [...]
> >>>> Jul 10 12:33:03 BMS_CNA04 kernel: [18136514.138968] DMA32: 188513*4kB 29459*8kB 2*16kB 2*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 990396kB
> >>>
> >>> Moreover your allocation request was oreder 2 and you do not have much
> >>> memory there because most of the free memory is in order-0-2.
> >>>
> >>
> >> Hi Michal,
> >>
> >> order=2 -> alloc 16kb memory, and DMA32 still has 2*16kB 2*32kB 1*64kB 1*512kB,
> >> so you mean this large buddy block was reclaimed during the moment of oom and
> >> print, right?
> >
> > Not really. Those high order blocks are inaccessible for your GFP_KERNEL
> > allocation. See __zone_watermark_ok.
> >
>
> I know, some of them are from reserved memory(MIGRATE_RESERVE), right?

No. The watermark is calculated per order. And you have almost all the
free memory in the lower orders. From a quick glance it seems that even
order-1 allocations wouldn't fit into min watermark.
--
Michal Hocko
SUSE Labs


\
 
 \ /
  Last update: 2015-07-14 11:41    [W:0.031 / U:23.564 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site