From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx187.postini.com [74.125.245.187]) by kanga.kvack.org (Postfix) with SMTP id 5627E6B004D for ; Tue, 31 Jul 2012 01:32:45 -0400 (EDT) From: Shawn Joo Date: Tue, 31 Jul 2012 13:32:36 +0800 Subject: RE: page allocation failure Message-ID: <5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B9DA@HKMAIL02.nvidia.com> References: <5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B900@HKMAIL02.nvidia.com> <20120730141329.GC9981@tiehlicka.suse.cz> In-Reply-To: <20120730141329.GC9981@tiehlicka.suse.cz> MIME-Version: 1.0 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B9DAHKMAIL02nvidi_" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: "linux-mm@kvack.org" , "andi@firstfloor.org" --_000_5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B9DAHKMAIL02nvidi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for attention and comment, here is following question. 1. In general if order 3(32KB) is required to be allocated, if "size-= 32768" cache does not have available slab, then "size-32768" will request= =20memory from buddy Here watermark is involved as important factor. (I would like to know how to increase the number of object on the cache, = because when cache is created by "kmem_cache_create", there is only objec= t size, but no number of the object) =F0 my understanding is correct?, please correct. 2. In my init.rc, min_free_order_shift is set to 4. If I decrease this value, it should be helpful. any recommend size of "min_free_order_shift"? If I can have doc about it,= =20it will be helpful. >> Although you have some order-3 pages the Normal zone is not balanced f= or that order most probably (see __zone_watermark_ok). I am afraid that I am not familiar with "watermark", anyway I will study = in detail. Looks "is not balanced" is related to watermark. Thanks, Seongho(Shawn) -----Original Message----- From: Michal Hocko [mailto:mhocko@suse.cz] Sent: Monday, July 30, 2012 11:13 PM To: Shawn Joo Cc: linux-mm@kvack.org; andi@firstfloor.org Subject: Re: page allocation failure On Mon 30-07-12 21:25:40, Shawn Joo wrote: > Dear experts, > > I have question about memory allocation failure on kernel 3.1. (simply > it seems there is available free memory, however "page allocation > failure" happened) > > While big data transfer, there is page allocation failure (please > check attached log) It happens on __alloc_skb(). Inside function, it > allocates memory from "skbuff_head_cache" and "size-xxxxxxx" caches. > > Here is my understanding, please correct me and advise. From the > kernel log, it failed when it tried to get 2^3*4K(=3D32KB) memory. (e.g= . > swapper: page allocation failure: order:3, mode:0x20) You are actually short on free memory (7M out of 700M). Although you have= =20some order-3 pages the Normal zone is not balanced for that order most= =20probably (see __zone_watermark_ok). Your allocation is GFP_ATOMIC and = that's why the process cannot sleep and wait for reclaim to free enough p= ages to satisfy this allocation. > From slabinfo, upper size-32768 does not have available slab, however > buddy still has available memory. so when 32KB(order:3) was required, > slab(size-32768) should request memory from buddy. e.g. "2" will be > decreased to "1" on buddyinfo and "size-32768" cache will get 32K > memory from buddy. So I can not understand why page alloc failure > happened even if there are many available memory on buddy. Please > advise on it. > > Here is dump info(page_allocation_failure_last_dump.txt), right after > issue happens. > (FYI at alloc failure, order:3) > cat /proc/buddyinfo > Node 0, zone Normal 949 0 0 2 3 3 0 = =20 0 1 1 0 > > root@android:/sdcard/modem_CoreDump # cat /proc/meminfo cat > /proc/meminfo > MemTotal: 747864 kB > MemFree: 7000 kB > Buffers: 5596 kB > Cached: 361884 kB > SwapCached: 0 kB > Active: 147068 kB > Inactive: 333448 kB > Active(anon): 113212 kB > Inactive(anon): 296 kB > Active(file): 33856 kB > Inactive(file): 333152 kB > Unevictable: 96 kB > Mlocked: 0 kB > HighTotal: 0 kB > HighFree: 0 kB > LowTotal: 747864 kB > LowFree: 7000 kB > SwapTotal: 0 kB > SwapFree: 0 kB > Dirty: 0 kB > Writeback: 0 kB > AnonPages: 113172 kB > Mapped: 44288 kB > Shmem: 376 kB > Slab: 15280 kB > SReclaimable: 7976 kB > SUnreclaim: 7304 kB > KernelStack: 3712 kB > PageTables: 5628 kB > NFS_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 373932 kB > Committed_AS: 2894244 kB > VmallocTotal: 131072 kB > VmallocUsed: 39136 kB > VmallocChunk: 76676 kB > DirectMap4k: 399364 kB > DirectMap2M: 370688 kB -- Michal Hocko SUSE Labs -------------------------------------------------------------------------= ---------- This email message is for the sole use of the intended recipient(s) and m= ay contain confidential information. Any unauthorized review, use, disclosure or di= stribution is prohibited. If you are not the intended recipient, please contact the= =20sender by reply email and destroy all copies of the original message. -------------------------------------------------------------------------= ---------- --_000_5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B9DAHKMAIL02nvidi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you= =20for attention and comment, here is following question.

<= p class=3DMsoPlainText> 

1.     = In general if order 3(32KB) is required to be allocated, if “= ;size-32768” cache does not have available slab, then “size-3= 2768” will request memory from buddy Here watermark is involved as = important factor.

(I would like to know how to increase the number of object= =20on the cache, because when cache is created by “kmem_cache_c= reate”, there is only object size, but no number of the object)

=F0  = my understanding is correct?, please correct.

 

2.     In my init.rc, min_free_order_shift is set to 4.

If I decrease this value= , it should be helpful.

any recommend size of “min_free_order_shift”= ;? If I can have doc about it, it will be helpful.

 

>> Although you have some order-3 pages the Norma= l zone is not balanced for that order most probably (see __zone_wa= termark_ok).

I am afraid tha= t I am not familiar with “watermark”, = anyway I will study in detail.

Look= s “is not balanced” is related to watermark.

 

 

Thanks,

Seongho(Shawn)

&n= bsp;

-----Original Message-----
From:= =20Michal Hocko [mailto:mhocko= @suse.cz]
Sent: Monday, July 30, 2012 11:13 PM
To: Shawn JooCc: linux-mm@kvack.org; andi@firstfloor.org
Subject: Re:= =20page allocation failure

&nb= sp;

On Mon 30-07-12 21:25:40, Shawn Joo = wrote:

> Dear experts,

>

= > I have question about memory allocation failure on kernel 3.1. (simp= ly

> it seems there is availabl= e free memory, however "page allocation

> failure" happened)

> 

> While big data= =20transfer, there is page allocation failure (please

> check attached log) It happens on __alloc_skb().= =A0 Inside function, it

> alloc= ates memory from "skbuff_head_cache" and "size-xxxxxxx&quo= t; caches.

> 

> Here is my understanding, please correct me= =20and advise.=A0 From the

> ke= rnel log, it failed when it tried to get 2^3*4K(=3D32KB) memory. (e.g.

> swapper: page allocation failure= : order:3, mode:0x20)

 

You are actually short on free memory (7M= =20out of 700M). Although you have some order-3 pages the Normal zone is = not balanced for that order most probably (see __zone_watermark_ok). Your= =20allocation is GFP_ATOMIC and that's why the process cannot sleep and w= ait for reclaim to free enough pages to satisfy this allocation.

 

> From slabinfo, upper size-32768 does not have available slab, howe= ver

> buddy still has available= =20memory. so when 32KB(order:3) was required,

> slab(size-32768) should request memory from buddy. e.g. = "2" will be

> decreas= ed to "1" on buddyinfo and "size-32768" cache will ge= t 32K

> memory from buddy.=A0 S= o I can not understand why page alloc failure

> happened even if there are many available memory on budd= y.=A0 Please

> advise on it.

> 

> Here is dump info(page_allocation_failure_last_dump.txt)= , right after

> issue happens.<= o:p>

> (FYI at alloc failure, order:3= )

> cat /proc/buddyinfo

> Node 0, zone=A0=A0 Normal=A0=A0=A0 949= =A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0 3=A0=A0= =A0=A0=A0 3=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0= =A0 1=A0=A0=A0=A0=A0 0

>

> root@android:/sdcard/modem_CoreDump = # cat /proc/meminfo cat

> /proc= /meminfo

> MemTotal:=A0=A0=A0=A0= =A0=A0=A0=A0 747864 kB

> MemFree= :=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 7000 kB

> Buffers:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 5596 kB=

> Cached:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 36= 1884 kB

> SwapCached:=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 0 kB

> Act= ive:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 147068 kB

> Inactive:=A0=A0=A0=A0=A0=A0=A0=A0 333448 kB

=

> Active(anon):=A0=A0=A0=A0 113212 kB

> Inactive(anon):=A0=A0=A0=A0=A0 296 kB<= o:p>

> Active(file):=A0=A0=A0=A0=A0 3= 3856 kB

> Inactive(file):=A0=A0 = 333152 kB

> Unevictable:=A0=A0=A0= =A0=A0=A0=A0=A0=A0 96 kB

> Mlock= ed:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 kB

> HighTotal:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 kB<= o:p>

> HighFree:=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 =A0=A0=A00 kB

> LowTot= al:=A0=A0=A0=A0=A0=A0=A0=A0 747864 kB

> LowFree:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 7000 kB

<= p class=3DMsoPlainText>> SwapTotal:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =200 kB

> SwapFree:=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 0 kB

> = Dirty:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 0 kB

> Writeback:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 0 kB

> AnonPages:=A0=A0=A0=A0= =A0=A0=A0 113172 kB

> Mapped:=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 44288 kB

> Shmem:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 376 kB

> Slab:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 15280 kB

> SReclaimable:=A0= =A0=A0=A0=A0=A0 7976 kB

> SUnrec= laim:=A0=A0=A0=A0=A0=A0=A0=A0 7304 kB

> KernelStack:=A0=A0=A0=A0=A0=A0=A0 3712 kB

> PageTables:=A0=A0=A0=A0=A0=A0=A0=A0 5628 kB<= /p>

> NFS_Unstable:=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 0 kB

> Bounce:=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 0 kB

&g= t; WritebackTmp:=A0=A0=A0=A0=A0=A0=A0=A0 =A00 kB

> CommitLimit:=A0=A0=A0=A0=A0 373932 kB

> Committed_AS:=A0=A0=A0 2894244 kB

> VmallocTotal:=A0=A0=A0=A0 131072 kB

> VmallocUsed:=A0=A0=A0=A0=A0=A0 39136 = kB

> VmallocChunk:=A0=A0=A0=A0=A0= =2076676 kB

> DirectMap4k:=A0=A0= =A0=A0=A0 399364 kB

> DirectMap2= M:=A0=A0=A0=A0=A0 370688 kB

--=

Michal Hocko

SUSE Labs

This email message is for the sole use of the intended recipient(s) = and may=20 contain confidential information.  Any unauthorized review, use, dis= closure=20 or distribution is prohibited.  If you are not the intended recipien= t,=20 please contact the sender by reply email and destroy all copies of the or= iginal=20 message.

--_000_5F2C6DA655B36C43B21C7FB179CEC9F4E3F157B9DAHKMAIL02nvidi_-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org