> >commit 944d9fec8d7aee3f2e16573e9b6a16634b33f403
> >Author: Luiz Capitulino
> >Date: Wed Jun 4 16:07:13 2014 -0700
> >
> >hugetlb: add support for gigantic page allocation at runtime
> >
> >
>
> Ah, thanks for your pointing out.
I should add the CMA allocation would still make sense, as
On Fri, Aug 22, 2014 at 09:34:30AM +0800, Zhang Yanfei wrote:
>Hello Wanpeng
>
>On 08/22/2014 07:37 AM, Wanpeng Li wrote:
>> Hi Andi,
>> On Fri, Apr 12, 2013 at 05:22:37PM +0200, Andi Kleen wrote:
>>> On Fri, Apr 12, 2013 at 07:29:07AM +0800, Wanpeng Li wrote:
Ping Andi,
On Thu, Apr 04, 2
Hello Wanpeng
On 08/22/2014 07:37 AM, Wanpeng Li wrote:
> Hi Andi,
> On Fri, Apr 12, 2013 at 05:22:37PM +0200, Andi Kleen wrote:
>> On Fri, Apr 12, 2013 at 07:29:07AM +0800, Wanpeng Li wrote:
>>> Ping Andi,
>>> On Thu, Apr 04, 2013 at 05:09:08PM +0800, Wanpeng Li wrote:
order >= MAX_ORDER pag
Hi Andi,
On Fri, Apr 12, 2013 at 05:22:37PM +0200, Andi Kleen wrote:
>On Fri, Apr 12, 2013 at 07:29:07AM +0800, Wanpeng Li wrote:
>> Ping Andi,
>> On Thu, Apr 04, 2013 at 05:09:08PM +0800, Wanpeng Li wrote:
>> >order >= MAX_ORDER pages are only allocated at boot stage using the
>> >bootmem allocat
On Fri, Apr 12, 2013 at 07:29:07AM +0800, Wanpeng Li wrote:
> Ping Andi,
> On Thu, Apr 04, 2013 at 05:09:08PM +0800, Wanpeng Li wrote:
> >order >= MAX_ORDER pages are only allocated at boot stage using the
> >bootmem allocator with the "hugepages=xxx" option. These pages are never
> >free after b
On Fri 05-04-13 16:54:44, Simon Jeons wrote:
> Hi Michal,
> On 04/05/2013 04:12 PM, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >>On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >>>On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> order >= MAX_ORDER pages ar
On Fri 05-04-13 16:27:59, Wanpeng Li wrote:
> On Fri, Apr 05, 2013 at 10:12:39AM +0200, Michal Hocko wrote:
> >On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> >> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >> >On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> >> >> order >= MAX_ORDER
Hi Michal,
On 04/05/2013 04:12 PM, Michal Hocko wrote:
On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
order >= MAX_ORDER pages are only allocated at boot stage using the
bootmem allocator wit
On Fri 05-04-13 07:41:23, Wanpeng Li wrote:
> On Thu, Apr 04, 2013 at 06:17:46PM +0200, Michal Hocko wrote:
> >On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> >> order >= MAX_ORDER pages are only allocated at boot stage using the
> >> bootmem allocator with the "hugepages=xxx" option. These pages ar
On Thu 04-04-13 18:17:46, Michal Hocko wrote:
> On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> > order >= MAX_ORDER pages are only allocated at boot stage using the
> > bootmem allocator with the "hugepages=xxx" option. These pages are never
> > free after boot by default since it would be a one-w
On Thu 04-04-13 17:09:08, Wanpeng Li wrote:
> order >= MAX_ORDER pages are only allocated at boot stage using the
> bootmem allocator with the "hugepages=xxx" option. These pages are never
> free after boot by default since it would be a one-way street(>= MAX_ORDER
> pages cannot be allocated lat
order >= MAX_ORDER pages are only allocated at boot stage using the
bootmem allocator with the "hugepages=xxx" option. These pages are never
free after boot by default since it would be a one-way street(>= MAX_ORDER
pages cannot be allocated later), but if administrator confirm not to
use these
12 matches
Mail list logo
