linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Masters <jcm@jonmasters.org>
To: David Miller <davem@davemloft.net>, glaubitz@physik.fu-berlin.de
Cc: kirill@shutemov.name, kirill.shutemov@linux.intel.com,
	linux-kernel@vger.kernel.org, ak@linux.intel.com,
	dave.hansen@intel.com, luto@amacapital.net, mhocko@suse.com,
	linux-arch@vger.kernel.org, linux-mm@kvack.org
Subject: Re: Question on the five-level page table support patches
Date: Tue, 25 Apr 2017 03:25:09 -0400	[thread overview]
Message-ID: <eb59ccee-f479-ef42-ebf5-f2fde2776709@jonmasters.org> (raw)
In-Reply-To: <20170424.180948.1311847745777709716.davem@davemloft.net>

On 04/24/2017 06:09 PM, David Miller wrote:
> From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Date: Mon, 24 Apr 2017 22:37:40 +0200
> 
>> Would be really nice to able to have a canonical solution for this issue,
>> it's been biting us on SPARC for quite a while now due to the fact that
>> virtual address space has been 52 bits on SPARC for a while now.
> 
> It's going to break again with things like ADI which encode protection
> keys in the high bits of the 64-bit virtual address.
> 
> Reallly, it would be nice if these tags were instead encoded in the
> low bits of suitably aligned memory allocations but I am sure it's to
> late to do that now.

I'm curious (and hey, ARM has 52-bit VAs coming[0] that was added in
ARMv8.2). Does anyone really think pointer tagging is a good idea for a
new architecture being created going forward? This could be archived
somewhere so that the folks in Berkeley and elsewhere have an answer.

As an aside, one of the reasons I've been tracking these Intel patches
personally is to figure out the best way to play out the ARMv8 story.
There isn't the same legacy of precompiled code out there (and the
things that broke and were fixed when moving from 42-bit to 48-bit VA
are already accounting for a later switch to 52-bit). I do find it
amusing that I proposed a solution similar Kirill's a year or so back to
some other folks elsewhere with a similar set of goals in mind.

Jon.

[0] Requires 64K pages on ARMv8. It's one of the previously unmentioned
reasons why RHEL for ARM was built with 64K granule size ;)

      reply	other threads:[~2017-04-25  7:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-23 10:53 Question on the five-level page table support patches John Paul Adrian Glaubitz
2017-04-24  5:11 ` Andy Lutomirski
2017-04-24 13:03   ` Andi Kleen
2017-04-24 20:33     ` John Paul Adrian Glaubitz
2017-04-24 16:19 ` Kirill A. Shutemov
2017-04-24 20:37   ` John Paul Adrian Glaubitz
2017-04-24 22:01     ` Kirill A. Shutemov
2017-04-24 22:09     ` David Miller
2017-04-25  7:25       ` Jon Masters [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=eb59ccee-f479-ef42-ebf5-f2fde2776709@jonmasters.org \
    --to=jcm@jonmasters.org \
    --cc=ak@linux.intel.com \
    --cc=dave.hansen@intel.com \
    --cc=davem@davemloft.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=mhocko@suse.com \
    /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).