From: Catalin Marinas <catalin.marinas@arm.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Muchun Song <muchun.song@linux.dev>,
Mina Almasry <almasrymina@google.com>,
kirill@shutemov.name, joel@joelfernandes.org,
william.kucharski@oracle.com, kaleshsingh@google.com,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, 21cnbao@gmail.com
Subject: Re: [PATCH v2 2/2] arm64: hugetlb: enable __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE
Date: Tue, 1 Aug 2023 12:09:47 +0100 [thread overview]
Message-ID: <ZMjn+68gKrdQSjMD@arm.com> (raw)
In-Reply-To: <20230801023145.17026-3-wangkefeng.wang@huawei.com>
On Tue, Aug 01, 2023 at 10:31:45AM +0800, Kefeng Wang wrote:
> +#define __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE
> +static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
> + unsigned long start,
> + unsigned long end)
> +{
> + unsigned long stride = huge_page_size(hstate_vma(vma));
> +
> + if (stride != PMD_SIZE && stride != PUD_SIZE)
> + stride = PAGE_SIZE;
> + __flush_tlb_range(vma, start, end, stride, false, 0);
We could use some hints here for the tlb_level (2 for pmd, 1 for pud).
Regarding the last_level argument to __flush_tlb_range(), I think it
needs to stay false since this function is also called on the
hugetlb_unshare_pmds() path where the pud is cleared and needs
invalidating.
That said, maybe you can rewrite it as a switch statement and call
flush_pmd_tlb_range() or flush_pud_tlb_range() (just make sure these are
defined when CONFIG_HUGETLBFS is enabled).
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Will Deacon <will@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Muchun Song <muchun.song@linux.dev>,
Mina Almasry <almasrymina@google.com>,
kirill@shutemov.name, joel@joelfernandes.org,
william.kucharski@oracle.com, kaleshsingh@google.com,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, 21cnbao@gmail.com
Subject: Re: [PATCH v2 2/2] arm64: hugetlb: enable __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE
Date: Tue, 1 Aug 2023 12:09:47 +0100 [thread overview]
Message-ID: <ZMjn+68gKrdQSjMD@arm.com> (raw)
In-Reply-To: <20230801023145.17026-3-wangkefeng.wang@huawei.com>
On Tue, Aug 01, 2023 at 10:31:45AM +0800, Kefeng Wang wrote:
> +#define __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE
> +static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma,
> + unsigned long start,
> + unsigned long end)
> +{
> + unsigned long stride = huge_page_size(hstate_vma(vma));
> +
> + if (stride != PMD_SIZE && stride != PUD_SIZE)
> + stride = PAGE_SIZE;
> + __flush_tlb_range(vma, start, end, stride, false, 0);
We could use some hints here for the tlb_level (2 for pmd, 1 for pud).
Regarding the last_level argument to __flush_tlb_range(), I think it
needs to stay false since this function is also called on the
hugetlb_unshare_pmds() path where the pud is cleared and needs
invalidating.
That said, maybe you can rewrite it as a switch statement and call
flush_pmd_tlb_range() or flush_pud_tlb_range() (just make sure these are
defined when CONFIG_HUGETLBFS is enabled).
--
Catalin
next prev parent reply other threads:[~2023-08-01 11:10 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-01 2:31 [PATCH v2 0/2] mm: hugetlb: fix mremap tlb flush Kefeng Wang
2023-08-01 2:31 ` Kefeng Wang
2023-08-01 2:31 ` [PATCH v2 1/2] mm: hugetlb: use flush_hugetlb_tlb_range() in move_hugetlb_page_tables() Kefeng Wang
2023-08-01 2:31 ` Kefeng Wang
2023-08-01 2:31 ` [PATCH v2 2/2] arm64: hugetlb: enable __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE Kefeng Wang
2023-08-01 2:31 ` Kefeng Wang
2023-08-01 2:31 ` Muchun Song
2023-08-01 2:31 ` Muchun Song
2023-08-01 11:09 ` Catalin Marinas [this message]
2023-08-01 11:09 ` Catalin Marinas
2023-08-01 11:22 ` Kefeng Wang
2023-08-01 11:22 ` Kefeng Wang
2023-08-01 13:36 ` Kefeng Wang
2023-08-01 13:36 ` Kefeng Wang
2023-08-01 13:56 ` [PATCH v3] " Kefeng Wang
2023-08-01 13:56 ` Kefeng Wang
2023-08-01 15:28 ` Catalin Marinas
2023-08-01 15:28 ` Catalin Marinas
2023-08-02 1:27 ` [PATCH v4] " Kefeng Wang
2023-08-02 1:27 ` Kefeng Wang
2023-08-02 1:40 ` Muchun Song
2023-08-02 1:40 ` Muchun Song
2023-08-02 10:41 ` Catalin Marinas
2023-08-02 10:41 ` Catalin Marinas
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=ZMjn+68gKrdQSjMD@arm.com \
--to=catalin.marinas@arm.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=almasrymina@google.com \
--cc=joel@joelfernandes.org \
--cc=kaleshsingh@google.com \
--cc=kirill@shutemov.name \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=wangkefeng.wang@huawei.com \
--cc=will@kernel.org \
--cc=william.kucharski@oracle.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.