Re: [RFC PATCH] arm64/hugetlb enable gigantic hugepage

2016-08-19 Thread Yisheng Xie
add more, hi all, Could anyone do me a favor and give some comments? Thanks Xie Yisheng On 2016/8/18 20:05, Xie Yisheng wrote: > As we know, arm64 also support gigantic hugepage eg. 1G. > So I try to use this function by adding hugepagesz=1G > in kernel parameters, with CONFIG_CMA=y. > However,

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
On 2016/7/19 22:14, Vlastimil Babka wrote: > On 07/19/2016 03:48 PM, Xishi Qiu wrote: >> On 2016/7/19 21:17, Vlastimil Babka wrote: >> >>> On 07/19/2016 02:43 PM, Yisheng Xie wrote: >>>> hi all, >>>> I'm getting a 2-order page allocation f

Re: [Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
On 2016/7/19 22:14, Vlastimil Babka wrote: > On 07/19/2016 03:48 PM, Xishi Qiu wrote: >> On 2016/7/19 21:17, Vlastimil Babka wrote: >> >>> On 07/19/2016 02:43 PM, Yisheng Xie wrote: >>>> hi all, >>>> I'm getting a 2-order page allocation f

[Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
hi all, I'm getting a 2-order page allocation failure problem on 4.1.18. >From the Mem-info, it seems the system have much zero order free pages which >can be used for memory compaction. Is it possible that the memory compacted by current process used by other process soon, which cause page

[Question]page allocation failure: order:2, mode:0x2000d1

2016-07-19 Thread Yisheng Xie
hi all, I'm getting a 2-order page allocation failure problem on 4.1.18. >From the Mem-info, it seems the system have much zero order free pages which >can be used for memory compaction. Is it possible that the memory compacted by current process used by other process soon, which cause page

<    4   5   6   7   8   9