Re: [RFC, PATCHv1 00/28] 5-level paging

On 12/08/2016 09:01 PM, Ingo Molnar wrote: >> > - Handle opt-in wider address space for userspace. >> > >> > Not all userspace is ready to handle addresses wider than current >> > 47-bits. At least some JIT compiler make use of upper bits to encode >> > their info. >> > >> > We

Re: [RFC, PATCHv1 00/28] 5-level paging

On 12/08/2016 09:01 PM, Ingo Molnar wrote: >> > - Handle opt-in wider address space for userspace. >> > >> > Not all userspace is ready to handle addresses wider than current >> > 47-bits. At least some JIT compiler make use of upper bits to encode >> > their info. >> > >> > We

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 08:40:11AM -0800, Andi Kleen wrote: > > On other hand, large virtual address space would put more pressure on > > cache -- at least one more page table per process, if we make 56-bit VA > > default. > > The top level page always has to be there unless you disable it at

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 08:40:11AM -0800, Andi Kleen wrote: > > On other hand, large virtual address space would put more pressure on > > cache -- at least one more page table per process, if we make 56-bit VA > > default. > > The top level page always has to be there unless you disable it at

Re: [RFC, PATCHv1 00/28] 5-level paging

On 12/09/2016 02:37 AM, Kirill A. Shutemov wrote: > On other hand, large virtual address space would put more pressure on > cache -- at least one more page table per process, if we make 56-bit VA > default. For a process only using a small amount of its address space, the mid-level paging

Re: [RFC, PATCHv1 00/28] 5-level paging

On 12/09/2016 02:37 AM, Kirill A. Shutemov wrote: > On other hand, large virtual address space would put more pressure on > cache -- at least one more page table per process, if we make 56-bit VA > default. For a process only using a small amount of its address space, the mid-level paging

Re: [RFC, PATCHv1 00/28] 5-level paging

> On other hand, large virtual address space would put more pressure on > cache -- at least one more page table per process, if we make 56-bit VA > default. The top level page always has to be there unless you disable it at boot time (unless you go for a scheme where some processes share top

Re: [RFC, PATCHv1 00/28] 5-level paging

> On other hand, large virtual address space would put more pressure on > cache -- at least one more page table per process, if we make 56-bit VA > default. The top level page always has to be there unless you disable it at boot time (unless you go for a scheme where some processes share top

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 11:24:12AM +0100, Arnd Bergmann wrote: > On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote: > > > - Handle opt-in wider address space for userspace. > > > > > > Not all userspace is ready to handle addresses wider than current > > > 47-bits. At least

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 11:24:12AM +0100, Arnd Bergmann wrote: > On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote: > > > - Handle opt-in wider address space for userspace. > > > > > > Not all userspace is ready to handle addresses wider than current > > > 47-bits. At least

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 06:01:30AM +0100, Ingo Molnar wrote: > > * Kirill A. Shutemov wrote: > > > x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB > > of physical address space. We are already bumping into this limit: some > > vendors

Re: [RFC, PATCHv1 00/28] 5-level paging

On Fri, Dec 09, 2016 at 06:01:30AM +0100, Ingo Molnar wrote: > > * Kirill A. Shutemov wrote: > > > x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB > > of physical address space. We are already bumping into this limit: some > > vendors offers servers with 64 TiB of

Re: [RFC, PATCHv1 00/28] 5-level paging

On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote: > > - Handle opt-in wider address space for userspace. > > > > Not all userspace is ready to handle addresses wider than current > > 47-bits. At least some JIT compiler make use of upper bits to encode > > their info. > >

Re: [RFC, PATCHv1 00/28] 5-level paging

On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote: > > - Handle opt-in wider address space for userspace. > > > > Not all userspace is ready to handle addresses wider than current > > 47-bits. At least some JIT compiler make use of upper bits to encode > > their info. > >

Re: [RFC, PATCHv1 00/28] 5-level paging

* Kirill A. Shutemov wrote: > x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB > of physical address space. We are already bumping into this limit: some > vendors offers servers with 64 TiB of memory today. > > To overcome the

Re: [RFC, PATCHv1 00/28] 5-level paging

* Kirill A. Shutemov wrote: > x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB > of physical address space. We are already bumping into this limit: some > vendors offers servers with 64 TiB of memory today. > > To overcome the limitation upcoming hardware will

Re: [RFC, PATCHv1 00/28] 5-level paging

On Thu, Dec 08, 2016 at 10:16:07AM -0800, Linus Torvalds wrote: > On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: > > > > This patchset is still very early. There are a number of things missing > > that we have to do before asking anyone to merge it

Re: [RFC, PATCHv1 00/28] 5-level paging

On Thu, Dec 08, 2016 at 10:16:07AM -0800, Linus Torvalds wrote: > On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: > > > > This patchset is still very early. There are a number of things missing > > that we have to do before asking anyone to merge it (listed below). > > It would be

Re: [RFC, PATCHv1 00/28] 5-level paging

On December 8, 2016 10:16:07 AM PST, Linus Torvalds wrote: >On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: >> >> This patchset is still very early. There are a number of things >missing >> that we have to do before

Re: [RFC, PATCHv1 00/28] 5-level paging

On December 8, 2016 10:16:07 AM PST, Linus Torvalds wrote: >On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov > wrote: >> >> This patchset is still very early. There are a number of things >missing >> that we have to do before asking anyone to merge it (listed below). >> It would be great if

Re: [RFC, PATCHv1 00/28] 5-level paging

On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov wrote: > > This patchset is still very early. There are a number of things missing > that we have to do before asking anyone to merge it (listed below). > It would be great if folks can start testing applications

Re: [RFC, PATCHv1 00/28] 5-level paging

On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov wrote: > > This patchset is still very early. There are a number of things missing > that we have to do before asking anyone to merge it (listed below). > It would be great if folks can start testing applications now (in QEMU) to > look for

[RFC, PATCHv1 00/28] 5-level paging

x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB of physical address space. We are already bumping into this limit: some vendors offers servers with 64 TiB of memory today. To overcome the limitation upcoming hardware will introduce support for 5-level paging[1]. It is a

[RFC, PATCHv1 00/28] 5-level paging

x86-64 is currently limited to 256 TiB of virtual address space and 64 TiB of physical address space. We are already bumping into this limit: some vendors offers servers with 64 TiB of memory today. To overcome the limitation upcoming hardware will introduce support for 5-level paging[1]. It is a