linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Christophe LEROY <christophe.leroy@c-s.fr>,
	benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
	Scott Wood <oss@buserror.net>
Subject: Re: [PATCH v4 2/3] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line
Date: Wed, 02 Aug 2017 13:01:21 +0530	[thread overview]
Message-ID: <877eym1l4m.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <64014b48-a04f-92a7-f561-7ffd386fabc6@c-s.fr>

Christophe LEROY <christophe.leroy@c-s.fr> writes:

> Hi,
>
> Le 28/07/2017 =C3=A0 07:01, Aneesh Kumar K.V a =C3=A9crit :
>> 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.
>>=20
>> W.r.t FSL support, we now limit our allocation range using BOOTMEM_ALLOC=
_ACCESSIBLE.
>>=20
>> We use the kernel command line to do reservation of hugetlb pages on pow=
ernv
>> platforms. On pseries hash mmu mode the supported gigantic huge page siz=
e 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 giga=
ntic
>> hugepage allocation based on hypervisor hint that is specified via
>> "ibm,expected#pages" property of the memory node.
>
> It looks like it doesn't work on the 8xx:
>
> root@vgoip:~# dmesg | grep -i huge
> [    0.000000] Kernel command line: console=3DttyCPM0,115200N8=20
> ip=3D172.25.231.25:172.25.231.1::255.0.0.0:vgoip:eth0:off hugepagesz=3D8M=
=20
> hugepages=3D4
> [    0.416722] HugeTLB registered 8.00 MiB page size, pre-allocated 4 pag=
es
> [    0.423184] HugeTLB registered 512 KiB page size, pre-allocated 0 pages
> root@vgoip:~# cat /proc/meminfo
> MemTotal:         123388 kB
> MemFree:           77900 kB
> MemAvailable:      78412 kB
> Buffers:               0 kB
> Cached:             3964 kB
> SwapCached:            0 kB
> Active:             3788 kB
> Inactive:           1680 kB
> Active(anon):       1636 kB
> Inactive(anon):       20 kB
> Active(file):       2152 kB
> Inactive(file):     1660 kB
> Unevictable:           0 kB
> Mlocked:               0 kB
> SwapTotal:             0 kB
> SwapFree:              0 kB
> Dirty:                 0 kB
> Writeback:             0 kB
> AnonPages:          1552 kB
> Mapped:             2404 kB
> Shmem:               152 kB
> Slab:                  0 kB
> SReclaimable:          0 kB
> SUnreclaim:            0 kB
> KernelStack:         304 kB
> PageTables:          208 kB
> NFS_Unstable:          0 kB
> Bounce:                0 kB
> WritebackTmp:          0 kB
> CommitLimit:       45308 kB
> Committed_AS:      16664 kB
> VmallocTotal:     866304 kB
> VmallocUsed:           0 kB
> VmallocChunk:          0 kB
> HugePages_Total:       0
> HugePages_Free:        0
> HugePages_Rsvd:        0
> HugePages_Surp:        0
> Hugepagesize:        512 kB

But you are printing above the default hugepaeg details. You haven't
changed that in kernel command line. What does
/sys/kernel/mm/hugepages/<hugepages-size>/nr_hugepages show ?

To change the default hugepage size you may want to use
default_hugepagesz=3D8M

-aneesh

  reply	other threads:[~2017-08-02  7:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-28  5:01 [PATCH v4 1/3] mm/hugetlb: Allow arch to override and call the weak function Aneesh Kumar K.V
2017-07-28  5:01 ` [PATCH v4 2/3] powerpc/mm/hugetlb: Add support for reserving gigantic huge pages via kernel command line Aneesh Kumar K.V
2017-08-02  6:13   ` Christophe LEROY
2017-08-02  7:31     ` Aneesh Kumar K.V [this message]
2017-08-02  8:10       ` Christophe LEROY
2017-08-02  8:52         ` Christophe LEROY
2017-07-28  5:01 ` [PATCH v4 3/3] powerpc/mm/hugetlb: Allow runtime allocation of 16G Aneesh Kumar K.V
2017-08-15 13:20 ` [PATCH v4 1/3] mm/hugetlb: Allow arch to override and call the weak function Michael Ellerman
2017-08-18 12:50 ` [v4, " Michael Ellerman

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=877eym1l4m.fsf@linux.vnet.ibm.com \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@c-s.fr \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).