| Message ID | 20231229082207.60235-1-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mm: memory: use nth_page() in clear/copy_subpage() | expand |
On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: > The clear and copy of huge gigantic page has converted to use nth_page() > to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP), > but not change for the non-gigantic part, fix it too. Can there be discontiguities within a non-gigantic huge page? My impression was that you can't have a discontiguity at such a small boundary.
On 29.12.23 09:49, Matthew Wilcox wrote: > On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: >> The clear and copy of huge gigantic page has converted to use nth_page() >> to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP), >> but not change for the non-gigantic part, fix it too. > > Can there be discontiguities within a non-gigantic huge page? My > impression was that you can't have a discontiguity at such a small > boundary. No, we can't. MAX_ORDER allocations from the buddy always completely fit into a memory section.
On 2023/12/29 19:15, David Hildenbrand wrote: > On 29.12.23 09:49, Matthew Wilcox wrote: >> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: >>> The clear and copy of huge gigantic page has converted to use nth_page() >>> to handle the possible discontinuous struct page(SPARSEMEM without >>> VMEMMAP), >>> but not change for the non-gigantic part, fix it too. >> >> Can there be discontiguities within a non-gigantic huge page? My >> impression was that you can't have a discontiguity at such a small >> boundary. > > No, we can't. MAX_ORDER allocations from the buddy always completely fit > into a memory section. On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section, right? But after v5.13 commit 782276b4d0ad ("arm64: Force SPARSEMEM_VMEMMAP as the only memory management model"), it looks only old lts, eg, 5.10 could meet this issue.
On 02.01.24 07:53, Kefeng Wang wrote: > > > On 2023/12/29 19:15, David Hildenbrand wrote: >> On 29.12.23 09:49, Matthew Wilcox wrote: >>> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: >>>> The clear and copy of huge gigantic page has converted to use nth_page() >>>> to handle the possible discontinuous struct page(SPARSEMEM without >>>> VMEMMAP), >>>> but not change for the non-gigantic part, fix it too. >>> >>> Can there be discontiguities within a non-gigantic huge page? My >>> impression was that you can't have a discontiguity at such a small >>> boundary. >> >> No, we can't. MAX_ORDER allocations from the buddy always completely fit >> into a memory section. > > On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section, > right? I recall the mem sections are always at least 128 MiB on arm64. Note that anything > MAX_ORDER is called a "gigantic huge page" in hugetlb code.
On 2024/1/3 0:11, David Hildenbrand wrote: > On 02.01.24 07:53, Kefeng Wang wrote: >> >> >> On 2023/12/29 19:15, David Hildenbrand wrote: >>> On 29.12.23 09:49, Matthew Wilcox wrote: >>>> On Fri, Dec 29, 2023 at 04:22:07PM +0800, Kefeng Wang wrote: >>>>> The clear and copy of huge gigantic page has converted to use >>>>> nth_page() >>>>> to handle the possible discontinuous struct page(SPARSEMEM without >>>>> VMEMMAP), >>>>> but not change for the non-gigantic part, fix it too. >>>> >>>> Can there be discontiguities within a non-gigantic huge page? My >>>> impression was that you can't have a discontiguity at such a small >>>> boundary. >>> >>> No, we can't. MAX_ORDER allocations from the buddy always completely fit >>> into a memory section. >> >> On ARM64, we have 32M(16*2M) HugeTLB, it maybe not within a mem section, >> right? > > I recall the mem sections are always at least 128 MiB on arm64. > > Note that anything > MAX_ORDER is called a "gigantic huge page" in > hugetlb code. Yes, we already check MAX_ORDER, please ignore this one, thanks. > >
diff --git a/mm/memory.c b/mm/memory.c index 5c757fba8858..173b9b696230 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -6039,7 +6039,7 @@ static int clear_subpage(unsigned long addr, int idx, void *arg) { struct page *page = arg; - clear_user_highpage(page + idx, addr); + clear_user_highpage(nth_page(page, idx), addr); return 0; } @@ -6089,10 +6089,11 @@ struct copy_subpage_arg { static int copy_subpage(unsigned long addr, int idx, void *arg) { struct copy_subpage_arg *copy_arg = arg; + struct page *dst = nth_page(copy_arg->dst, idx); + struct page *src = nth_page(copy_arg->src, idx); - if (copy_mc_user_highpage(copy_arg->dst + idx, copy_arg->src + idx, - addr, copy_arg->vma)) { - memory_failure_queue(page_to_pfn(copy_arg->src + idx), 0); + if (copy_mc_user_highpage(dst, src, addr, copy_arg->vma)) { + memory_failure_queue(page_to_pfn(src), 0); return -EHWPOISON; } return 0;
The clear and copy of huge gigantic page has converted to use nth_page() to handle the possible discontinuous struct page(SPARSEMEM without VMEMMAP), but not change for the non-gigantic part, fix it too. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- mm/memory.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)