Message ID | 20240301091455.246686-1-alexghiti@rivosinc.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2097:b0:108:e6aa:91d0 with SMTP id gs23csp955126dyb; Fri, 1 Mar 2024 01:16:08 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCUGDo5WHoVzS+i/57yZ+bfG5tL+MCsmBkcyepRs8w2BiYDO2njgXqhUyFcPOwgTE8Gntuo5Pf4tz55HRgPvKhxveIgb5Q== X-Google-Smtp-Source: AGHT+IGKxEz0ITS/I5ag9gjoWiBiAkk2nHOHLAKuIeh2pt3zGzC7OFfAf1/89ZBGUCztSaGzZgtQ X-Received: by 2002:a17:906:27db:b0:a43:dd85:e171 with SMTP id k27-20020a17090627db00b00a43dd85e171mr726653ejc.69.1709284568192; Fri, 01 Mar 2024 01:16:08 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709284568; cv=pass; d=google.com; s=arc-20160816; b=ZMco8ujCc9Y+kY00GuOGmHGyUFfVc1iWrW1tqL8bwCbb/B3F5JeLS2MvRl3nBOby7g 3b5hvd4EtDR9ubvXQ2xJJHLWkYBF9L2bZQJALYnUqTWvYmJHyGtU2h1JuAnzbaUgKy/7 x22JIq4bu8Q8cYeJu6dwELVZsQA+ig6zET8mtfceGnuAU8N+GxhK7+dVt4Qm5vhJksKX GwY5J+WStO/l7zKZxfCiGswMMFM7cYVTsZMMe7oExzEjygt4Gf6w/OOqw85vPZAqutXR 4GZulkNWZc71lIuzcSeeOf1WblI9+SbGWO9mlyiyoEaZwkyeSPrzu6kbUqzp/C4g2gGV A3xQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=yprVHevcC7ppzCMdOTaT3VuCvD5AQnHTkhMmW9/Yos8=; fh=JfWhlPNimaKua+aPS5efjRwr90+O7REg7DsXljX8RwI=; b=Uej/EecV8HKJKOYoKhfo95e8Pm/UFwHWZAWdnSZJct7Scp+CEvlZU4P03jDzDH5ItV F8MinsFOCiZ5VaIA/mUW+V3nXOLFV7ZVRxjOXr8OFIpXhw17GytndZAgj/BHOo7qKsa5 x0l1O2Y3BfMj/JoDAFGr++51Y8+9S2lc7JiIwUzR3kPNs+Ua6IY+/XIz57H3ga7UMrSd 0eqM9Wd1aziJLjmK3Te1ErEp1DroomAfizPvnFnQ7qspoCxHarIJJgWEr9YgRKuyOTkG WpzowlEAh7AxhlgN0lzpGqrX8RFr9tmLtPywnF8OClHYEiGxC71IixR5VGAGSUlvn1m7 8tpA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Aheax1MW; arc=pass (i=1 spf=pass spfdomain=rivosinc.com dkim=pass dkdomain=rivosinc-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org" Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id k4-20020a170906578400b00a446c7790dcsi682661ejq.247.2024.03.01.01.16.08 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 01:16:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=Aheax1MW; arc=pass (i=1 spf=pass spfdomain=rivosinc.com dkim=pass dkdomain=rivosinc-com.20230601.gappssmtp.com); spf=pass (google.com: domain of linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-88156-ouuuleilei=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id CA58F1F26967 for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 09:16:07 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9748E6A8C6; Fri, 1 Mar 2024 09:15:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b="Aheax1MW" Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08B8E6A333 for <linux-kernel@vger.kernel.org>; Fri, 1 Mar 2024 09:15:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.52 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709284516; cv=none; b=HtDKKbfyx0ejvJdZ16vQatD7sBI01ZPg1zap6uQIhYNmaLC/E7MYMyzhIDyAJTr4yZWk14hx/2WNX/Q8Pe/UqLsolM5nZ0hXNazjWN35rxRV1p11bF20YPkomy9rNo4u3fjdK0Nth7i2d7NxMSM2HV/vJccJnRpOo5HA3PptlQo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709284516; c=relaxed/simple; bh=tygbM0Nx204YWVn0xR7lvxEmcEDYSAVTdjNO1AFVCW0=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=Gdrjn2e1nInB8rfFOwXzk/ZUmr0/ous5ktODgNrWZ5WmfLdqkNURgNIqN1xEraT08M34M8Fvd+ShS2sfPwc9hCBsm/9s215ugwEvhEBZZrVnrrkmtFHrG0rz8aQb+5AgApDduiUSw0pAvZ27UVqnLbwsoRZXfgvWHTx5RyRsBxM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com; spf=pass smtp.mailfrom=rivosinc.com; dkim=pass (2048-bit key) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.b=Aheax1MW; arc=none smtp.client-ip=209.85.221.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-33d38c9ca5bso902127f8f.2 for <linux-kernel@vger.kernel.org>; Fri, 01 Mar 2024 01:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1709284512; x=1709889312; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yprVHevcC7ppzCMdOTaT3VuCvD5AQnHTkhMmW9/Yos8=; b=Aheax1MWECDmSkRbYs+jWeYwHCclhaa0KCo7ak+xiUPHkv7JhVV7L1MDXpLhHRjTV3 WdLFXpr6oBA7f+kJScZLFBaKl8c7L+O7u4gbQ3jqe0jGObxCQijzdro5ALdU9Icg16t+ I0FlYXPXPwytxdf7qJLyY+fz2eHHm4NOqTiSFCuEjkrmXjoFItmJvs2ydMnHXEXl24V9 +ZOUYV/MqxTr/Sdw1spB+lBc50FmrnCekiuquSEaSxborj08UUJnuIPkGN7ry8EL0v4i PoVZ9HT+pTn4iaum1OQzicI9316Yk6MAaZiLHhqKxlRvvRwcggN/L7Z0N6l61KA8CzW8 GaVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709284512; x=1709889312; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yprVHevcC7ppzCMdOTaT3VuCvD5AQnHTkhMmW9/Yos8=; b=XLp8Ewgp2IN+fvuqrUNCHAgjqMBNGPirVfjBuscOlNUZ/lJMnEOrjgqhknLqo5FdfD 5+9kpTV/ViKB8MTvrdtKIVUnpePPPq0sYPXBoV6nXyEePOgHYSXNtDMtL2sqX5F5qTYE U2Wa8+Eb7/UCrniJ4/+SRZtqhwgXw7rH20yAb3N0482V7RS5JiLYtFXAyMNhzDHbBEFa CQ9HzGMvULxsUxIQcZyXtkLxuep0+HqnL2Yy1l3kvFeOQsx5R96kdUtBIeXK4IQRYu4z Vo1+ZMht645RGzLFzNi2gaPfZDjAp4lKEX5M617IpVx/O2HIlO2f0H3Jv9Pf0DGC0bCq 3Z/Q== X-Forwarded-Encrypted: i=1; AJvYcCWeDDuHjBscr3mQzarnDGL5/Sx0C20rnn8RRmkQ6cwaZZxPNAKILuHqAt1IyqnT+uYG/9oUt5hQCgKLcjXgdqQhLC0ue2UDCpQTThe5 X-Gm-Message-State: AOJu0YzCLXAj8a4Zm9INYiTkrBKt4c+lbZtP7NCs66qUQdCHsZ440MaF m+xzeKCUkpt8b+JRQgPIM36eBv7fp+PmXEeYB3kCH+jOYfDrhItkNIINVGgrDbc= X-Received: by 2002:a5d:5284:0:b0:33e:d27:2e40 with SMTP id c4-20020a5d5284000000b0033e0d272e40mr820688wrv.11.1709284512017; Fri, 01 Mar 2024 01:15:12 -0800 (PST) Received: from alex-rivos.ba.rivosinc.com (amontpellier-656-1-456-62.w92-145.abo.wanadoo.fr. [92.145.124.62]) by smtp.gmail.com with ESMTPSA id b3-20020a5d5503000000b0033dabeacab2sm4022712wrv.39.2024.03.01.01.15.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 01:15:11 -0800 (PST) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>, Mark Rutland <mark.rutland@arm.com>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Andrew Morton <akpm@linux-foundation.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-mm@kvack.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Subject: [PATCH 0/9] Merge arm64/riscv hugetlbfs contpte support Date: Fri, 1 Mar 2024 10:14:46 +0100 Message-Id: <20240301091455.246686-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.39.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792314775447088415 X-GMAIL-MSGID: 1792314775447088415 |
Series |
Merge arm64/riscv hugetlbfs contpte support
|
|
Message
Alexandre Ghiti
March 1, 2024, 9:14 a.m. UTC
This patchset intends to merge the contiguous ptes hugetlbfs implementation of arm64 and riscv. Both arm64 and riscv support the use of contiguous ptes to map pages that are larger than the default page table size, respectively called contpte and svnapot. The riscv implementation differs from the arm64's in that the LSBs of the pfn of a svnapot pte are used to store the size of the mapping, allowing for future sizes to be added (for now only 64KB is supported). That's an issue for the core mm code which expects to find the *real* pfn a pte points to. Patch 1 fixes that by always returning svnapot ptes with the real pfn and restores the size of the mapping when it is written to a page table. The following patches are just merges of the 2 different implementations that currently exist in arm64 and riscv which are very similar. It paves the way to the reuse of the recent contpte THP work by Ryan [1] to avoid reimplementing the same in riscv. This patchset was tested by running the libhugetlbfs testsuite with 64KB and 2MB pages on both architectures (on a 4KB base page size arm64 kernel). [1] https://lore.kernel.org/linux-arm-kernel/20240215103205.2607016-1-ryan.roberts@arm.com/ Alexandre Ghiti (9): riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code riscv: Safely remove huge_pte_offset() when manipulating NAPOT ptes mm: Use common huge_ptep_get() function for riscv/arm64 mm: Use common set_huge_pte_at() function for riscv/arm64 mm: Use common huge_pte_clear() function for riscv/arm64 mm: Use common huge_ptep_get_and_clear() function for riscv/arm64 mm: Use common huge_ptep_set_access_flags() function for riscv/arm64 mm: Use common huge_ptep_set_wrprotect() function for riscv/arm64 mm: Use common huge_ptep_clear_flush() function for riscv/arm64 arch/arm64/Kconfig | 1 + arch/arm64/include/asm/pgtable.h | 59 +++++- arch/arm64/mm/hugetlbpage.c | 291 +--------------------------- arch/riscv/Kconfig | 1 + arch/riscv/include/asm/hugetlb.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 11 ++ arch/riscv/include/asm/pgtable.h | 120 +++++++++++- arch/riscv/mm/hugetlbpage.c | 227 ---------------------- mm/Kconfig | 3 + mm/Makefile | 1 + mm/contpte.c | 268 +++++++++++++++++++++++++ 11 files changed, 456 insertions(+), 528 deletions(-) create mode 100644 mm/contpte.c
Comments
Hi Alexandre, I confess I haven't looked at the patches yet, but this cover letter raises a few quesions for me. I'll aim to look at the actual patches in due course. On 01/03/2024 09:14, Alexandre Ghiti wrote: > This patchset intends to merge the contiguous ptes hugetlbfs implementation > of arm64 and riscv. > > Both arm64 and riscv support the use of contiguous ptes to map pages that > are larger than the default page table size, respectively called contpte > and svnapot. > > The riscv implementation differs from the arm64's in that the LSBs of the > pfn of a svnapot pte are used to store the size of the mapping, allowing > for future sizes to be added (for now only 64KB is supported). That's an > issue for the core mm code which expects to find the *real* pfn a pte points > to. Patch 1 fixes that by always returning svnapot ptes with the real pfn > and restores the size of the mapping when it is written to a page table. Yes that makes sense to me. The intention for mTHP (!hugetlb) is to fully encapsulate PTEs beind set_ptes(), ptep_get() and friends, so what's actually written to the pgtable is arch-specific and well abstracted. > > The following patches are just merges of the 2 different implementations > that currently exist in arm64 and riscv which are very similar. It paves > the way to the reuse of the recent contpte THP work by Ryan [1] to avoid > reimplementing the same in riscv. You seem to be talking about both hugetlb (which uses the "huge" pte helpers) and contpte for THP (i.e. mTHP, which uses the regular pte helpers). They are pretty separate in my mind, so not sure why you would be modifying them both in the same series? Thanks, Ryan > > This patchset was tested by running the libhugetlbfs testsuite with 64KB > and 2MB pages on both architectures (on a 4KB base page size arm64 kernel). > > [1] https://lore.kernel.org/linux-arm-kernel/20240215103205.2607016-1-ryan.roberts@arm.com/ > > Alexandre Ghiti (9): > riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code > riscv: Safely remove huge_pte_offset() when manipulating NAPOT ptes > mm: Use common huge_ptep_get() function for riscv/arm64 > mm: Use common set_huge_pte_at() function for riscv/arm64 > mm: Use common huge_pte_clear() function for riscv/arm64 > mm: Use common huge_ptep_get_and_clear() function for riscv/arm64 > mm: Use common huge_ptep_set_access_flags() function for riscv/arm64 > mm: Use common huge_ptep_set_wrprotect() function for riscv/arm64 > mm: Use common huge_ptep_clear_flush() function for riscv/arm64 > > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/pgtable.h | 59 +++++- > arch/arm64/mm/hugetlbpage.c | 291 +--------------------------- > arch/riscv/Kconfig | 1 + > arch/riscv/include/asm/hugetlb.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 11 ++ > arch/riscv/include/asm/pgtable.h | 120 +++++++++++- > arch/riscv/mm/hugetlbpage.c | 227 ---------------------- > mm/Kconfig | 3 + > mm/Makefile | 1 + > mm/contpte.c | 268 +++++++++++++++++++++++++ > 11 files changed, 456 insertions(+), 528 deletions(-) > create mode 100644 mm/contpte.c >
Hi Ryan, On Fri, Mar 1, 2024 at 11:45 AM Ryan Roberts <ryan.roberts@arm.com> wrote: > > Hi Alexandre, > > I confess I haven't looked at the patches yet, but this cover letter raises a > few quesions for me. I'll aim to look at the actual patches in due course. > > On 01/03/2024 09:14, Alexandre Ghiti wrote: > > This patchset intends to merge the contiguous ptes hugetlbfs implementation > > of arm64 and riscv. > > > > Both arm64 and riscv support the use of contiguous ptes to map pages that > > are larger than the default page table size, respectively called contpte > > and svnapot. > > > > The riscv implementation differs from the arm64's in that the LSBs of the > > pfn of a svnapot pte are used to store the size of the mapping, allowing > > for future sizes to be added (for now only 64KB is supported). That's an > > issue for the core mm code which expects to find the *real* pfn a pte points > > to. Patch 1 fixes that by always returning svnapot ptes with the real pfn > > and restores the size of the mapping when it is written to a page table. > > Yes that makes sense to me. The intention for mTHP (!hugetlb) is to fully > encapsulate PTEs beind set_ptes(), ptep_get() and friends, so what's actually > written to the pgtable is arch-specific and well abstracted. > > > > > The following patches are just merges of the 2 different implementations > > that currently exist in arm64 and riscv which are very similar. It paves > > the way to the reuse of the recent contpte THP work by Ryan [1] to avoid > > reimplementing the same in riscv. > > You seem to be talking about both hugetlb (which uses the "huge" pte helpers) > and contpte for THP (i.e. mTHP, which uses the regular pte helpers). They are > pretty separate in my mind, so not sure why you would be modifying them both in > the same series? I don't, this patchset only deals with hugetlb, I just meant that this series was just the beginning as I'm working on moving the contpte for THP support in the generic code for riscv to use. Sorry my wording was ambiguous :) Thanks, Alex > > Thanks, > Ryan > > > > > This patchset was tested by running the libhugetlbfs testsuite with 64KB > > and 2MB pages on both architectures (on a 4KB base page size arm64 kernel). > > > > [1] https://lore.kernel.org/linux-arm-kernel/20240215103205.2607016-1-ryan.roberts@arm.com/ > > > > Alexandre Ghiti (9): > > riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code > > riscv: Safely remove huge_pte_offset() when manipulating NAPOT ptes > > mm: Use common huge_ptep_get() function for riscv/arm64 > > mm: Use common set_huge_pte_at() function for riscv/arm64 > > mm: Use common huge_pte_clear() function for riscv/arm64 > > mm: Use common huge_ptep_get_and_clear() function for riscv/arm64 > > mm: Use common huge_ptep_set_access_flags() function for riscv/arm64 > > mm: Use common huge_ptep_set_wrprotect() function for riscv/arm64 > > mm: Use common huge_ptep_clear_flush() function for riscv/arm64 > > > > arch/arm64/Kconfig | 1 + > > arch/arm64/include/asm/pgtable.h | 59 +++++- > > arch/arm64/mm/hugetlbpage.c | 291 +--------------------------- > > arch/riscv/Kconfig | 1 + > > arch/riscv/include/asm/hugetlb.h | 2 +- > > arch/riscv/include/asm/pgtable-64.h | 11 ++ > > arch/riscv/include/asm/pgtable.h | 120 +++++++++++- > > arch/riscv/mm/hugetlbpage.c | 227 ---------------------- > > mm/Kconfig | 3 + > > mm/Makefile | 1 + > > mm/contpte.c | 268 +++++++++++++++++++++++++ > > 11 files changed, 456 insertions(+), 528 deletions(-) > > create mode 100644 mm/contpte.c > > >
On 01/03/2024 11:29, Alexandre Ghiti wrote: > Hi Ryan, > > On Fri, Mar 1, 2024 at 11:45 AM Ryan Roberts <ryan.roberts@arm.com> wrote: >> >> Hi Alexandre, >> >> I confess I haven't looked at the patches yet, but this cover letter raises a >> few quesions for me. I'll aim to look at the actual patches in due course. >> >> On 01/03/2024 09:14, Alexandre Ghiti wrote: >>> This patchset intends to merge the contiguous ptes hugetlbfs implementation >>> of arm64 and riscv. >>> >>> Both arm64 and riscv support the use of contiguous ptes to map pages that >>> are larger than the default page table size, respectively called contpte >>> and svnapot. >>> >>> The riscv implementation differs from the arm64's in that the LSBs of the >>> pfn of a svnapot pte are used to store the size of the mapping, allowing >>> for future sizes to be added (for now only 64KB is supported). That's an >>> issue for the core mm code which expects to find the *real* pfn a pte points >>> to. Patch 1 fixes that by always returning svnapot ptes with the real pfn >>> and restores the size of the mapping when it is written to a page table. >> >> Yes that makes sense to me. The intention for mTHP (!hugetlb) is to fully >> encapsulate PTEs beind set_ptes(), ptep_get() and friends, so what's actually >> written to the pgtable is arch-specific and well abstracted. >> >>> >>> The following patches are just merges of the 2 different implementations >>> that currently exist in arm64 and riscv which are very similar. It paves >>> the way to the reuse of the recent contpte THP work by Ryan [1] to avoid >>> reimplementing the same in riscv. >> >> You seem to be talking about both hugetlb (which uses the "huge" pte helpers) >> and contpte for THP (i.e. mTHP, which uses the regular pte helpers). They are >> pretty separate in my mind, so not sure why you would be modifying them both in >> the same series? > > I don't, this patchset only deals with hugetlb, I just meant that this > series was just the beginning as I'm working on moving the contpte for > THP support in the generic code for riscv to use. Ahh got it! Thanks for the explanation. > > Sorry my wording was ambiguous :) > > Thanks, > > Alex > >> >> Thanks, >> Ryan >> >>> >>> This patchset was tested by running the libhugetlbfs testsuite with 64KB >>> and 2MB pages on both architectures (on a 4KB base page size arm64 kernel). >>> >>> [1] https://lore.kernel.org/linux-arm-kernel/20240215103205.2607016-1-ryan.roberts@arm.com/ >>> >>> Alexandre Ghiti (9): >>> riscv: Restore the pfn in a NAPOT pte when manipulated by core mm code >>> riscv: Safely remove huge_pte_offset() when manipulating NAPOT ptes >>> mm: Use common huge_ptep_get() function for riscv/arm64 >>> mm: Use common set_huge_pte_at() function for riscv/arm64 >>> mm: Use common huge_pte_clear() function for riscv/arm64 >>> mm: Use common huge_ptep_get_and_clear() function for riscv/arm64 >>> mm: Use common huge_ptep_set_access_flags() function for riscv/arm64 >>> mm: Use common huge_ptep_set_wrprotect() function for riscv/arm64 >>> mm: Use common huge_ptep_clear_flush() function for riscv/arm64 >>> >>> arch/arm64/Kconfig | 1 + >>> arch/arm64/include/asm/pgtable.h | 59 +++++- >>> arch/arm64/mm/hugetlbpage.c | 291 +--------------------------- >>> arch/riscv/Kconfig | 1 + >>> arch/riscv/include/asm/hugetlb.h | 2 +- >>> arch/riscv/include/asm/pgtable-64.h | 11 ++ >>> arch/riscv/include/asm/pgtable.h | 120 +++++++++++- >>> arch/riscv/mm/hugetlbpage.c | 227 ---------------------- >>> mm/Kconfig | 3 + >>> mm/Makefile | 1 + >>> mm/contpte.c | 268 +++++++++++++++++++++++++ >>> 11 files changed, 456 insertions(+), 528 deletions(-) >>> create mode 100644 mm/contpte.c >>> >>