Re: [PATCH] hugetlbfs: add MTE support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/15/24 3:31 AM, Catalin Marinas wrote:
Sorry for the delay (holidays etc.)

On Tue, Jul 09, 2024 at 10:42:58AM -0700, Yang Shi wrote:
On 7/4/24 6:44 AM, Catalin Marinas wrote:
It might be better to convert those page flag checks to only happen on
the head page. My stashed changes from over a year ago (before we had
more folio conversions) below. However, as I mentioned, I got stuck on
folio_copy() which also does a cond_resched() between copy_highpage().
We can have the page flags set for head only for hugetlb page. For
copy_highpage(), we should be able to do something like the below:

if  page_is_head && page_is_hugetlb && page_has_mte_tagged
     set page_mte_tagged flags
     copy tags for all sub pages
else // <-- tail page or non-hugetlb page
     current copy_highpage implementation
Ah, so you want in the first copy_highpage() for the head page to
populate the tags for the tail pages. I guess this would work.

Yes, because we know the order of hugetlb page so we know how many tail pages we need populate tags for.

A deeper look showed this may be the only way to do it (if we want to have mte page flag for head only) because process_huge_page() may starting copy from the middle of huge page to have hot sub pages in cache. The process_huge_page() is used by hugetlb fork and COW. I think it is safe to do so in fork and COW path too since the destination hugetlb page won't be seen by the users until fork or COW fault is done.


The hugetlb folio can't go away under us since migration path should pin it
so the status of folio is stable. The preemption caused by cond_resched()
should be fine too due to the pin and the page table entry keeps being
migration entry until migration is done, so every one should just see
migration entry and wait for migration is done.
Yeah, I don't see those pages going away, otherwise folio_copy() would
corrupt data.

The other concerned user of copy_highpage() is uprobe, but it also pins the
page then doing copy and it is called with holding write mmap_lock.

IIUC, it should work if I don't miss something. This also should have no
impact on HVO. The overhead for other users of copy_highpage() should be
also acceptable.
I also think so. We also have the copy_user_highpage() on arm64 that
calls copy_highpage() but I think that's also safe.

Yes, it is used by fork and COW fault by hugetlb.







[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux