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 memory 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 object size, but no number of the object) ð 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 Normal zone is not balanced for 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----- 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(=32KB) 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 some order-3 pages the Normal zone is not balanced for that order most probably (see __zone_watermark_ok). Your allocation is GFP_ATOMIC and that's why the process cannot sleep and wait for reclaim to free enough pages 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 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 may
contain confidential information. Any unauthorized review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of the original
message.
|