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 breaki
On 06/22/2016 12:20 PM, Andy Lutomirski wrote:
>>> >> As an example, a 32-bit x86 program really could have something mapped
>>> >> above the 32-bit boundary. It just wouldn't be useful, but the kernel
>>> >> should still understand that it's *user* memory.
>>> >>
>>> >> So you'd have PR_SET_MMAP_
+Andy, Cyrill, Dmitry who have been discussing variable TASK_SIZE on x86
on linux-mm
http://marc.info/?l=linux-mm&m=146290118818484&w=2
>>> On 04/28/2016 09:00 AM, Maxim Kuvyrkov wrote:
This is a summary of discussions we had on IRC between kernel and
toolchain engineers regarding suppo
For info Google v8 Javascript uses the bottom bit to tag pointers. One
problem with this mechanism though is that the pointers can only be used
directly with unscaled offset memory access instructions (LDUR/STUR). So in
particular, no LDP/STP.
On 28 April 2016 at 22:41, Wookey wrote:
> +++ Adhem
+++ Adhemerval Zanella [2016-04-28 12:07 -0300]:
> I do not think this issue is inherent to all JIT implements, but rather to
> luajit with its NaN-tagging scheme [1] which packs different types of objects
> in a 8-byte.
Other jits use the same/similar schemes (mozilla's ionmonkey is one
AIUI). N
On 28 April 2016 at 14:24, Peter Maydell wrote:
> On 28 April 2016 at 14:17, Arnd Bergmann wrote:
>> One simple (from the kernel's perspective, not from the JIT) approach
>> might be to always use MAP_FIXED whenever an allocation is made for
>> memory that needs these special pointers, and then m
I do not think this issue is inherent to all JIT implements, but rather to
luajit with its NaN-tagging scheme [1] which packs different types of objects
in a 8-byte. It works well with x86_64 that limits the VMA to 47-bits, but
things get messy with large VMA support. Luajit work around this issue
FWIW: OpenJDK assumes 48 bit virtual address. There is no inherent
reason for this other than we do
movz/movk/movk
to form an address. It is relatively trivial to change this to
movz/movk/movk/movk
All the best,
Ed.
On 28 April 2016 at 14:00, Maxim Kuvyrkov wrote:
> This is a summary of dis
On 28 April 2016 at 14:17, Arnd Bergmann wrote:
> One simple (from the kernel's perspective, not from the JIT) approach
> might be to always use MAP_FIXED whenever an allocation is made for
> memory that needs these special pointers, and then manage the available
> address space explicitly. Would
On Thursday 28 April 2016 16:00:22 Maxim Kuvyrkov wrote:
> This is a summary of discussions we had on IRC between kernel and toolchain
> engineers regarding support for JITs and 52-bit virtual address space (mostly
> in the context of LuaJIT, but this concerns other JITs too).
>
> The summary is
This is a summary of discussions we had on IRC between kernel and toolchain
engineers regarding support for JITs and 52-bit virtual address space (mostly
in the context of LuaJIT, but this concerns other JITs too).
The summary is that we need to consider ways of reducing the size of VA for a
gi
11 matches
Mail list logo
