From: Mark Rutland <mark.rutland@arm.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: Chaitanya S Prakash <chaitanyas.prakash@arm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 0/5] selftests/mm: Implement support for arm64 on va
Date: Thu, 23 Mar 2023 11:59:14 +0000 [thread overview]
Message-ID: <ZBw/CVePzmshvMu7@FVFF77S0Q05N> (raw)
In-Reply-To: <20230323111436.mj2kbesfxfmvj5by@box.shutemov.name>
On Thu, Mar 23, 2023 at 02:14:36PM +0300, Kirill A. Shutemov wrote:
> On Thu, Mar 23, 2023 at 04:22:38PM +0530, Chaitanya S Prakash wrote:
> > The va_128TBswitch selftest is designed and implemented for PowerPC and
> > x86 architectures which support a 128TB switch, up to 256TB of virtual
> > address space and hugepage sizes of 16MB and 2MB respectively. Arm64
> > platforms on the other hand support a 256Tb switch, up to 4PB of virtual
> > address space and a default hugepage size of 512MB when 64k pagesize is
> > enabled.
> >
> > These architectural differences require introducing support for arm64
> > platforms, after which a more generic naming convention is suggested.
> > The in code comments are amended to provide a more platform independent
> > explanation of the working of the code and nr_hugepages are configured
> > as required. Finally, the file running the testcase is modified in order
> > to prevent skipping of hugetlb testcases of va_high_addr_switch.
> >
> > This series has been tested on 6.3.0-rc3 kernel, both on arm64 and x86
> > platforms.
> >
> > Cc: Andrew Morton <akpm@linux-foundation.org>
> > Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > Cc: Shuah Khan <shuah@kernel.org>
> > Cc: linux-mm@kvack.org
> > Cc: linux-kselftest@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> >
> > Chaitanya S Prakash (5):
> > selftests/mm: Add support for arm64 platform on va switch
> > selftests/mm: Rename va_128TBswitch to va_high_addr_switch
> > selftests/mm: Add platform independent in code comments
> > selftests/mm: Configure nr_hugepages for arm64
> > selftests/mm: Run hugetlb testcases of va switch
> >
> > tools/testing/selftests/mm/Makefile | 4 +-
> > tools/testing/selftests/mm/run_vmtests.sh | 12 +++++-
> > ...va_128TBswitch.c => va_high_addr_switch.c} | 41 +++++++++++++++----
> > ..._128TBswitch.sh => va_high_addr_switch.sh} | 6 ++-
> > 4 files changed, 49 insertions(+), 14 deletions(-)
> > rename tools/testing/selftests/mm/{va_128TBswitch.c => va_high_addr_switch.c} (86%)
> > rename tools/testing/selftests/mm/{va_128TBswitch.sh => va_high_addr_switch.sh} (89%)
>
> The patchset looks sane to me, but I have question: why arm64 has switch
> on 256TB. The reason we have the switch is to keep system backward
> compatible.
It's the same reason, it's just that arm64 initially supported 48-bits / 256TB
of user addresses (0x0000000000000000..0x0000ffffffffffff), while x86_64
supported 47-bits / 128TB (0x0000000000000000..0x00007fffffffffff).
Note: arm64 has separate page tables for the user / kernel halves of the VA
space, which in practice means we get an extra bit of address range for each
half.
> Maybe it is better to make arm64 switch also on 128TB to make it
> compatible across architectures?
I don't think that's something that we can change; user addresses between 128TB
and 256TB have been the case for over a decade now, and avoiding that by
default could easily break something.
Thanks,
Mark.
next prev parent reply other threads:[~2023-03-23 11:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 10:52 Chaitanya S Prakash
2023-03-23 10:52 ` [PATCH 1/5] selftests/mm: Add support for arm64 platform on va switch Chaitanya S Prakash
2023-03-23 10:52 ` [PATCH 2/5] selftests/mm: Rename va_128TBswitch to va_high_addr_switch Chaitanya S Prakash
2023-03-23 10:52 ` [PATCH 3/5] selftests/mm: Add platform independent in code comments Chaitanya S Prakash
2023-03-23 10:52 ` [PATCH 4/5] selftests/mm: Configure nr_hugepages for arm64 Chaitanya S Prakash
2023-03-23 10:52 ` [PATCH 5/5] selftests/mm: Run hugetlb testcases of va switch Chaitanya S Prakash
2023-03-23 11:14 ` [PATCH 0/5] selftests/mm: Implement support for arm64 on va Kirill A. Shutemov
2023-03-23 11:59 ` Mark Rutland [this message]
2023-03-23 21:49 ` Andrew Morton
2023-03-24 10:15 ` Anshuman Khandual
2023-04-05 4:22 ` Chaitanya S Prakash
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=ZBw/CVePzmshvMu7@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=chaitanyas.prakash@arm.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kirill@shutemov.name \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shuah@kernel.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