linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: James Houghton <jthoughton@google.com>,
	Matthew Wilcox <willy@infradead.org>
Cc: Khalid Aziz <khalid.aziz@oracle.com>,
	Peter Xu <peterx@redhat.com>,
	Vishal Moola <vishal.moola@gmail.com>,
	Jane Chu <jane.chu@oracle.com>,
	Muchun Song <muchun.song@linux.dev>,
	linux-mm@kvack.org
Subject: Re: Unifying page table walkers
Date: Fri, 7 Jun 2024 09:15:15 +0200	[thread overview]
Message-ID: <45a47fdd-f22b-42fb-b515-639b9ca6129e@redhat.com> (raw)
In-Reply-To: <CADrL8HVJTocuyCWgva_aavBA5X_6bmdN-sQ7FYS7vs6zqSDgUA@mail.gmail.com>

On 07.06.24 01:07, James Houghton wrote:
> On Thu, Jun 6, 2024 at 2:21 PM Matthew Wilcox <willy@infradead.org> wrote:
>>
>> On Thu, Jun 06, 2024 at 01:23:08PM -0700, James Houghton wrote:
>>> On Thu, Jun 6, 2024 at 1:04 PM Matthew Wilcox <willy@infradead.org> wrote:
>>>> Right, so we ignore hugetlb_fault() and call into __handle_mm_fault().
>>>> Once there, we'll do:
>>>>
>>>>          vmf.pud = pud_alloc(mm, p4d, address);
>>>>          if (pud_none(*vmf.pud) &&
>>>>              thp_vma_allowable_order(vma, vm_flags,
>>>>                                  TVA_IN_PF | TVA_ENFORCE_SYSFS, PUD_ORDER)) {
>>>>                  ret = create_huge_pud(&vmf);
>>>>
>>>> which will call vma->vm_ops->huge_fault(vmf, PUD_ORDER);
>>>>
>>>> So all we need to do is implement huge_fault in hugetlb_vm_ops.  I
>>>> don't think that's the same as creating a hugetlbfs2 because it's just
>>>> another entry point.  You can mmap() the same file both ways and it's
>>>> all cache coherent.
>>>
>>> That makes a lot of sense. FWIW, this sounds good to me (though I'm
>>> curious what Peter thinks :)).
>>>
>>> But I think you'll need to be careful to ensure that, for now anyway,
>>> huge_fault() is always called with the exact same ptep/pmdp/pudp that
>>> hugetlb_walk() would have returned (ignoring sharing). If you allow
>>> PMD mapping of what would otherwise be PUD-mapped hugetlb pages right
>>> now, you'll break the vmemmap optimization (and probably other
>>> things).
>>
>> Why is that?  This sounds like you know something I don't ;-)
>> Is it the mapcount issue?
> 
> Yeah, that's what I was thinking about. But I guess whether or not you
> are compatible with the vmemmap optimization depends on what
> mapcounting scheme you use. If you just use the THP one, you're going
> to end up incrementing _mapcount on the subpages, and that won't work.
> 
> I'm not immediately thinking of other things that would break... need
> to think some more.

If we're only concerned about unifying most page table walkers there is 
little reason to mess with mapcounts of hugetlb at this point. mapcounts 
with hugetlb only come into play once we support partial mappings, and I 
consider that yet another step (mapping/unmapping code) than unifying 
most page table walkers like Oscar+Peter have on their plate.

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-06-07  7:15 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06 18:29 Matthew Wilcox
2024-06-06 19:30 ` James Houghton
2024-06-06 20:04   ` Matthew Wilcox
2024-06-06 20:23     ` James Houghton
2024-06-06 21:21       ` Matthew Wilcox
2024-06-06 23:07         ` James Houghton
2024-06-07  7:15           ` David Hildenbrand [this message]
2024-06-06 21:33     ` Peter Xu
2024-06-06 21:49 ` Peter Xu
2024-06-07  5:07   ` Oscar Salvador
2024-06-07  6:59 ` David Hildenbrand
2024-06-09 20:08   ` Matthew Wilcox
2024-06-09 20:28     ` David Hildenbrand

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=45a47fdd-f22b-42fb-b515-639b9ca6129e@redhat.com \
    --to=david@redhat.com \
    --cc=jane.chu@oracle.com \
    --cc=jthoughton@google.com \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=muchun.song@linux.dev \
    --cc=peterx@redhat.com \
    --cc=vishal.moola@gmail.com \
    --cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox