lkml.org 
[lkml]   [2022]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 07/26] hugetlb: add hugetlb_pte to track HugeTLB page table entries
    On Tue, Jul 12, 2022 at 10:42:17AM +0100, Dr. David Alan Gilbert wrote:
    > * Mike Kravetz (mike.kravetz@oracle.com) wrote:
    > > On 06/24/22 17:36, James Houghton wrote:
    > > > After high-granularity mapping, page table entries for HugeTLB pages can
    > > > be of any size/type. (For example, we can have a 1G page mapped with a
    > > > mix of PMDs and PTEs.) This struct is to help keep track of a HugeTLB
    > > > PTE after we have done a page table walk.
    > >
    > > This has been rolling around in my head.
    > >
    > > Will this first use case (live migration) actually make use of this
    > > 'mixed mapping' model where hugetlb pages could be mapped at the PUD,
    > > PMD and PTE level all within the same vma? I only understand the use
    > > case from a high level. But, it seems that we would want to only want
    > > to migrate PTE (or PMD) sized pages and not necessarily a mix.
    >
    > I suspect we would pick one size and use that size for all transfers
    > when in postcopy; not sure if there are any side cases though.

    Yes, I'm also curious whether the series can be much simplified if we have
    a static way to do sub-page mappings, e.g., when sub-page mapping enabled
    we always map to PAGE_SIZE only; if not we keep the old hpage size mappings
    only.

    > > Looking to the future when supporting memory error handling/page poisoning
    > > it seems like we would certainly want multiple size mappings.

    If we treat page poisoning as very rare events anyway, IMHO it'll even be
    acceptable if we always split 1G pages into 4K ones but only rule out the
    real poisoned 4K phys page. After all IIUC the major goal is for reducing
    poisoned memory footprint.

    It'll be definitely nicer if we can keep 511 2M pages and 511 4K pages in
    that case so the 511 2M pages performs slightly better, but it'll be
    something extra to me. It can always be something worked upon a simpler
    version of sub-page mapping which is only PAGE_SIZE based.

    Thanks,

    --
    Peter Xu

    \
     
     \ /
      Last update: 2022-07-15 18:37    [W:4.288 / U:0.512 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site