All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
To: christophe leroy <christophe.leroy@c-s.fr>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au
Cc: Scott Wood <oss@buserror.net>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line
Date: Thu, 1 Jun 2017 12:11:29 -0700	[thread overview]
Message-ID: <1fc6f24e-2022-883a-fc90-8d629a181285@linux.vnet.ibm.com> (raw)
In-Reply-To: <b785b7b4-d6ee-3884-c140-74499171518c@c-s.fr>

On 06/01/2017 09:42 AM, christophe leroy wrote:
> 
> 
> Le 01/06/2017 à 16:30, Aneesh Kumar K.V a écrit :
>> With commit aa888a74977a8 ("hugetlb: support larger than MAX_ORDER") we added
>> support for allocating gigantic hugepages via kernel command line. Switch
>> ppc64 arch specific code to use that.
> 
> Is it only ppc64 ? Your patch removes things defined for the 8xx and 
> modifies stuff in init_32.c
> 
> On the 8xx, as far as I remember, 8M pages on 4k pages mode are above 
> default MAX_ORDER, I solved it by increasing MAX_ORDER. Is that wrong ?
> 
>>
>> W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC_ACCESSIBLE.
>>
>> We use the kernel command line to do reservation of hugetlb pages on powernv
>> platforms. On pseries hash mmu mode the supported gigantic huge page size is
>> 16GB and that can only be allocated with hypervisor assist. For pseries the
>> command line option doesn't do the allocation. Instead pseries does gigantic
>> hugepage allocation based on hypervisor hint that is specified via
>> "ibm,expected#pages" property of the memory node.
>>
>> Cc: Scott Wood <oss@buserror.net>
>> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> ---
>>  arch/powerpc/include/asm/book3s/64/mmu-hash.h |   2 +-
>>  arch/powerpc/include/asm/hugetlb.h            |  14 --
>>  arch/powerpc/kernel/setup-common.c            |   7 -
>>  arch/powerpc/mm/hash_utils_64.c               |   2 +-
>>  arch/powerpc/mm/hugetlbpage.c                 | 177 +++-----------------------
>>  arch/powerpc/mm/init_32.c                     |   2 -
>>  6 files changed, 22 insertions(+), 182 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> index 6981a52b3887..67766e60a6b6 100644
>> --- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> +++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
>> @@ -468,7 +468,7 @@ extern int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
>>  			     int psize, int ssize);
>>  int htab_remove_mapping(unsigned long vstart, unsigned long vend,
>>  			int psize, int ssize);
>> -extern void add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages);
>> +extern void pSeries_add_gpage(u64 addr, u64 page_size, unsigned long number_of_pages);
> 
> Linux kernel coding style says 'mixed-case names are frowned upon'

True, but there is precedent within arch/powerpc/platforms/pseries seeing as "pSeries_" is
already used heavily to prefix function names.

-Tyrel

> 
> Christophe
> 
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
> https://www.avast.com/antivirus
> 

  reply	other threads:[~2017-06-01 19:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-01 14:30 [PATCH v2 1/2] mm/hugetlb: Allow arch to override and call the weak function Aneesh Kumar K.V
2017-06-01 14:30 ` [PATCH v2 2/2] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line Aneesh Kumar K.V
2017-06-01 16:42   ` christophe leroy
2017-06-01 19:11     ` Tyrel Datwyler [this message]
2017-06-02  3:03       ` Michael Ellerman
2017-06-05  7:47         ` Aneesh Kumar K.V
2017-06-05  7:47     ` Aneesh Kumar K.V
2017-06-09 16:13       ` Christophe LEROY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1fc6f24e-2022-883a-fc90-8d629a181285@linux.vnet.ibm.com \
    --to=tyreld@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=oss@buserror.net \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.