On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov"
wrote:
>On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
>> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
>> wrote:
>> > Here' my first attempt to bring boot-time
On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov"
wrote:
>On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
>> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
>> wrote:
>> > Here' my first attempt to bring boot-time between 4- and 5-level
>paging.
>> > It looks not too
On May 26, 2017 12:23:18 PM PDT, Dave Hansen wrote:
>On 05/26/2017 11:24 AM, h...@zytor.com wrote:
>> The only case where that even has any utility is for an application
>> to want more than 128 TiB address space on a machine with no more
>> than 64 TiB of RAM. It is kind
On May 26, 2017 12:23:18 PM PDT, Dave Hansen wrote:
>On 05/26/2017 11:24 AM, h...@zytor.com wrote:
>> The only case where that even has any utility is for an application
>> to want more than 128 TiB address space on a machine with no more
>> than 64 TiB of RAM. It is kind of a narrow use case, I
On May 26, 2017 8:51:48 AM PDT, Linus Torvalds
wrote:
>On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> wrote:
>>
>> I don't see how kernel threads can use 4-level paging. It doesn't
>work
>> from virtual memory layout POV. Kernel claims
On May 26, 2017 8:51:48 AM PDT, Linus Torvalds
wrote:
>On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> wrote:
>>
>> I don't see how kernel threads can use 4-level paging. It doesn't
>work
>> from virtual memory layout POV. Kernel claims half of full virtual
>address
>> space for itself --
On 05/26/2017 11:24 AM, h...@zytor.com wrote:
> The only case where that even has any utility is for an application
> to want more than 128 TiB address space on a machine with no more
> than 64 TiB of RAM. It is kind of a narrow use case, I think.
Doesn't more address space increase the
On 05/26/2017 11:24 AM, h...@zytor.com wrote:
> The only case where that even has any utility is for an application
> to want more than 128 TiB address space on a machine with no more
> than 64 TiB of RAM. It is kind of a narrow use case, I think.
Doesn't more address space increase the
On Fri, May 26, 2017 at 8:58 AM, Kirill A. Shutemov
wrote:
>
> It's in a separate white paper for now:
>
> https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
Thanks. It didn't show up with "LA57 site:intel.com" with google,
which is
On Fri, May 26, 2017 at 8:58 AM, Kirill A. Shutemov
wrote:
>
> It's in a separate white paper for now:
>
> https://software.intel.com/sites/default/files/managed/2b/80/5-level_paging_white_paper.pdf
Thanks. It didn't show up with "LA57 site:intel.com" with google,
which is how I tried to find it
On Fri, May 26, 2017 at 08:51:48AM -0700, Linus Torvalds wrote:
> On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> wrote:
> >
> > I don't see how kernel threads can use 4-level paging. It doesn't work
> > from virtual memory layout POV. Kernel claims half of full
On Fri, May 26, 2017 at 08:51:48AM -0700, Linus Torvalds wrote:
> On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> wrote:
> >
> > I don't see how kernel threads can use 4-level paging. It doesn't work
> > from virtual memory layout POV. Kernel claims half of full virtual address
> > space
On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
wrote:
>
> I don't see how kernel threads can use 4-level paging. It doesn't work
> from virtual memory layout POV. Kernel claims half of full virtual address
> space for itself -- 256 PGD entries, not one as we would
On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
wrote:
>
> I don't see how kernel threads can use 4-level paging. It doesn't work
> from virtual memory layout POV. Kernel claims half of full virtual address
> space for itself -- 256 PGD entries, not one as we would effectively have
> in case
> Even ignoring all of above, I don't see much benefit of having per-mm
> switching. It adds complexity without much benefit -- saving few lines of
> logic during early boot doesn't look as huge win to me.
Also giving kthreads a different VM would prevent lazy VM switching
when switching from/to
> Even ignoring all of above, I don't see much benefit of having per-mm
> switching. It adds complexity without much benefit -- saving few lines of
> logic during early boot doesn't look as huge win to me.
Also giving kthreads a different VM would prevent lazy VM switching
when switching from/to
On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> wrote:
> > Here' my first attempt to bring boot-time between 4- and 5-level paging.
> > It looks not too terrible to me. I've expected it to be
On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> wrote:
> > Here' my first attempt to bring boot-time between 4- and 5-level paging.
> > It looks not too terrible to me. I've expected it to be worse.
>
> If I read this right,
On Thu, May 25, 2017 at 9:18 PM, Kevin Easton wrote:
> (If it weren't for that, maybe you could point the last entry in the PML4
> at the PML4 itself, so it also works as a PML5 for accessing kernel
> addresses? And of course make sure nothing gets loaded above
>
On Thu, May 25, 2017 at 9:18 PM, Kevin Easton wrote:
> (If it weren't for that, maybe you could point the last entry in the PML4
> at the PML4 itself, so it also works as a PML5 for accessing kernel
> addresses? And of course make sure nothing gets loaded above
> 0xff80).
This was an
On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
> wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> > wrote:
> >> Here' my first attempt to bring
On Thu, May 25, 2017 at 05:40:16PM -0700, Andy Lutomirski wrote:
> On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
> wrote:
> > On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> > wrote:
> >> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> >> It looks not too
On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> wrote:
>> Here' my first attempt to bring boot-time between 4- and 5-level paging.
>> It looks not too terrible to me.
On Thu, May 25, 2017 at 4:24 PM, Linus Torvalds
wrote:
> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
> wrote:
>> Here' my first attempt to bring boot-time between 4- and 5-level paging.
>> It looks not too terrible to me. I've expected it to be worse.
>
> If I read this right, you just
On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
wrote:
> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> It looks not too terrible to me. I've expected it to be worse.
If I read this right, you just made it a global on/off thing.
On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
wrote:
> Here' my first attempt to bring boot-time between 4- and 5-level paging.
> It looks not too terrible to me. I've expected it to be worse.
If I read this right, you just made it a global on/off thing.
May I suggest possibly a different
Here' my first attempt to bring boot-time between 4- and 5-level paging.
It looks not too terrible to me. I've expected it to be worse.
The basic idea is to implement the same logic as pgtable-nop4d.h provides,
but at runtime.
Runtime folding is only implemented for CONFIG_X86_5LEVEL=y case.
Here' my first attempt to bring boot-time between 4- and 5-level paging.
It looks not too terrible to me. I've expected it to be worse.
The basic idea is to implement the same logic as pgtable-nop4d.h provides,
but at runtime.
Runtime folding is only implemented for CONFIG_X86_5LEVEL=y case.
28 matches
Mail list logo