From: Dave Hansen <dave.hansen@intel.com>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Christopher Covington <cov@codeaurora.org>,
Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org>,
Linaro Dev Mailman List <linaro-dev@lists.linaro.org>,
Arnd Bergmann <arnd.bergmann@linaro.org>,
Mark Brown <broonie@linaro.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Dmitry Safonov <dsafonov@virtuozzo.com>
Subject: Re: JITs and 52-bit VA
Date: Wed, 22 Jun 2016 13:41:40 -0700 [thread overview]
Message-ID: <576AF804.3090901@intel.com> (raw)
In-Reply-To: <20160622201754.GD2045@uranus.lan>
On 06/22/2016 01:17 PM, Cyrill Gorcunov wrote:
> On Wed, Jun 22, 2016 at 12:56:56PM -0700, Dave Hansen wrote:
>>
>> Yeah, cgroups don't make a lot of sense.
>>
>> On x86, the 48-bit virtual address is even hard-coded in the ABI[1]. So
>> we can't change *any* program's layout without either breaking the ABI
>> or having it opt in.
>>
>> But, we're also lucky to only have one VA layout since day one.
>>
>> 1. www.x86-64.org/documentation/abi.pdf - a??... Therefore, conforming
>> processes may only use addresses from 0x00000000 00000000 to 0x00007fff
>> ffffffff .a??
>
> Yes, but noone forces you to write conforming programs ;)
> After all while hw allows you to run VA with bits > than
> 48 it's fine, all side effects of breaking abi is up to
> program author (iirc on x86 there is up to 52 bits on
> hw level allowed, don't have specs under my hands?)
My point was that you can't restrict the vaddr space without breaking
the ABI because apps expect to be able to use 0x00007fffffffffff. You
also can't extend the vaddr space because apps can *also* expect that
there are no valid vaddrs past 0x00007fffffffffff.
So, whatever happens here, at least on x86, we can't do anything to the
vaddr space without it being an opt-in for *each* *app*.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-06-22 20:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4A8E6E6D-6CF7-4964-A62E-467AE287D415@linaro.org>
2016-06-22 14:53 ` JITs and 52-bit VA Christopher Covington
2016-06-22 15:13 ` Andy Lutomirski
2016-06-22 19:18 ` Cyrill Gorcunov
2016-06-22 19:20 ` Andy Lutomirski
2016-06-22 19:44 ` Cyrill Gorcunov
2016-06-22 20:46 ` Andy Lutomirski
2016-06-22 21:38 ` Cyrill Gorcunov
2016-06-22 19:56 ` Dave Hansen
2016-06-22 20:10 ` Cyrill Gorcunov
2016-06-22 20:17 ` Cyrill Gorcunov
2016-06-22 20:24 ` Kirill A. Shutemov
2016-06-22 20:41 ` Dave Hansen [this message]
2016-06-22 21:06 ` Cyrill Gorcunov
2016-06-23 8:20 ` Dmitry Safonov
2016-06-22 15:40 ` Kirill A. Shutemov
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=576AF804.3090901@intel.com \
--to=dave.hansen@intel.com \
--cc=arnd.bergmann@linaro.org \
--cc=broonie@linaro.org \
--cc=cov@codeaurora.org \
--cc=dsafonov@virtuozzo.com \
--cc=gorcunov@gmail.com \
--cc=linaro-dev@lists.linaro.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=maxim.kuvyrkov@linaro.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.