From: steve.capper@linaro.org (Steve Capper)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] arm64: Add support for 48-bit Physical Addresses
Date: Thu, 28 Nov 2013 09:29:34 +0000 [thread overview]
Message-ID: <20131128092933.GA8642@linaro.org> (raw)
In-Reply-To: <1385537665-5909-1-git-send-email-mohun106@gmail.com>
On Wed, Nov 27, 2013 at 01:04:23PM +0530, mohun106 at gmail.com wrote:
> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
>
> This patch series provides an implementation of supporting 48-bit
> Physical Addresses for ARMv8 platforms. It is the maximum width that
> any ARMv8 based processor can support.
>
> The implementation extends the existing support of 40-bit PA.The kernel
> and user space will now be able to access 128TB each. With 4KB page size
> the Linux now will be using 4 levels of page tables by making use of
> 'pud'. And with 64KB page size the Linux will be using 3 levels of page
> tables.
>
> The code has been tested with LTP.
Hello,
Could you please test how this series interacts with huge pages?
So please run LTP with THP enabled and always active:
TRANSPARENT_HUGEPAGE=y
TRANSPARENT_HUGEPAGE_ALWAYS=y
(for both 4KB and 64KB base page sizes).
This will give the pmd level code a workout.
Then could you please try libhugetlbfs to test HugeTLB?
git://git.code.sf.net/p/libhugetlbfs/code (next branch)
with the following enabled:
HUGETLBFS=y
Please run the test suite against 2MB, 1GB (4KB base pages) and 512MB
(64KB base pages) huge pages.
To set aside 1GB huge pages at boot time, please add the following to
the kernel command line:
hugepagesz=1G hugepages=x
where x is the number of 1GB huge pages you can get away with :-).
For 2MB and 512MB:
echo x > /proc/sys/vm/nr_hugepages
again where x is the number of huge pages to set aside.
Ensure that the hugetlbfs filesystem is mounted:
mount -t hugetlbfs hugetlbfs /mnt/hugepages
Then
make check
The libhugetlbfs tests above will test out the pud and pmd interactions,
please let me know whether or not anything breaks.
Thanks,
--
Steve
prev parent reply other threads:[~2013-11-28 9:29 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-27 7:34 [RFC PATCH 0/2] arm64: Add support for 48-bit Physical Addresses mohun106 at gmail.com
2013-11-27 7:34 ` [RFC PATCH 1/2] arm64: Add 48-bit PA support for 4KB page size mohun106 at gmail.com
2013-11-27 11:14 ` Mark Rutland
2013-11-27 16:00 ` Radha Mohan
2013-11-27 7:34 ` [RFC PATCH 2/2] arm64: Add 48-bit PA support for 64KB " mohun106 at gmail.com
2013-11-27 11:30 ` Mark Rutland
2013-11-27 11:04 ` [RFC PATCH 0/2] arm64: Add support for 48-bit Physical Addresses Marc Zyngier
2013-11-27 15:33 ` Radha Mohan
2013-11-27 15:50 ` Will Deacon
2013-11-27 17:59 ` Marc Zyngier
2013-11-28 2:14 ` Radha Mohan
2013-12-05 14:35 ` Radha Mohan
2013-12-05 15:10 ` Marc Zyngier
2013-12-05 17:30 ` Catalin Marinas
2013-12-10 16:53 ` Radha Mohan
2013-12-10 17:02 ` Catalin Marinas
2013-12-11 9:18 ` Radha Mohan
2013-12-05 16:53 ` Catalin Marinas
2013-11-28 9:29 ` Steve Capper [this message]
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=20131128092933.GA8642@linaro.org \
--to=steve.capper@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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).