From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BBEA8C7EE29 for ; Thu, 25 May 2023 18:05:41 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4QRwvl4r8Tz3fFC for ; Fri, 26 May 2023 04:05:39 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=NoHSm+P+; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::b35; helo=mail-yb1-xb35.google.com; envelope-from=vishal.moola@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=NoHSm+P+; dkim-atps=neutral Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4QRwth5hqTz3f8j for ; Fri, 26 May 2023 04:04:42 +1000 (AEST) Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-ba94605bcd5so1224620276.2 for ; Thu, 25 May 2023 11:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685037879; x=1687629879; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YHz1MnM6TYYio2C+7LZLfrVXy67ugaabkk4Lxt+VEKA=; b=NoHSm+P+R3f9P1hTtI0Aa2538QwCPLtSoQPrBLURQdxmp107FQ1F0pBnbEQWwggzlT fiTACnc6uzA/OAWqwR1JVWYYICkwBDdnIXj4ERwntlgZc/Oij0dm8rv+0LrV+CltMo3B fKyXLHfkdRh4xQKVcMe8OCp5giU3Tnn12LZCznOtQl1pIuAziPLT4fePeWe5Cvh7ZNzP bRQ3kdfBju0tbpe4F8kOJL6Oz3PfBgKD+/0uu8kOUyKFxwwoV5gkGDAbnMcHEgSeCLSi HSGZ+QgYvXiydUgpNmaTWLnoPbGEK3dVe0T9hw+SN0OStPQTocdixTet+7JhvERZXcH+ xYiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685037879; x=1687629879; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YHz1MnM6TYYio2C+7LZLfrVXy67ugaabkk4Lxt+VEKA=; b=krT8IxkrQGkjSq8nbf6GOjs0kw6Vpy/rFig9IgW1WehMLUfj8guW9Qcq+mRAyMgAq2 HAPrCgo6w3skNuhQT+fYYfAkC3iqzUo1oMgwfogKiQjVyMX0FeM1yCKfHL+3DSxSG9EB pWOLaXnOx3YoYCATIAqY4OT/R0xmno9zdLFavxmb5ji0AkEuYiqdOyT9UijqYtJ4e0KJ hJ3Bv2xm3zWY5y6/6V3+slVoGYrh/kVqaoeQ5GRXYIl2q2UpdWPGABny7BITlQzTU0Oe ZMURyw4k2Qrec8lryBcZb2/uJBqtF7QkMy46wTYpMVszwlBjoVg1Wx3WpQ18PiaQ/PLO TBbw== X-Gm-Message-State: AC+VfDy7MjrS6Zrgk3wOp0MHTngpTyX5BrxFX00pI0H7fVh0hnDIPF/e E3Qh2Q7calxcVTUShAtBb9/US0ljf2LpSZEdNOc= X-Google-Smtp-Source: ACHHUZ7leu3e42UYud7EgWJZoN6PW1XGYdS9PCBG/tq5rzS7YnuUSWzFoklHW8B2kAANtPb/IRvLBp1ufSDbPWAmKj4= X-Received: by 2002:a25:7493:0:b0:ba8:15a3:f2e4 with SMTP id p141-20020a257493000000b00ba815a3f2e4mr4848492ybc.0.1685037879336; Thu, 25 May 2023 11:04:39 -0700 (PDT) MIME-Version: 1.0 References: <20230501192829.17086-1-vishal.moola@gmail.com> <20230501192829.17086-6-vishal.moola@gmail.com> <20230525090956.GX4967@kernel.org> In-Reply-To: <20230525090956.GX4967@kernel.org> From: Vishal Moola Date: Thu, 25 May 2023 11:04:28 -0700 Message-ID: Subject: Re: [PATCH v2 05/34] mm: add utility functions for ptdesc To: Mike Rapoport Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-arch@vger.kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, linux-openrisc@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-sh@vger.kernel.org, linux-um@lists.infradead.org, linux-mips@vger.kernel.org, linux-csky@vger.kernel.org, linux-mm@kvack.org, linux-m68k@lists.linux-m68k.org, Matthew Wilcox , loongarch@lists.linux.dev, sparclinux@vger.kernel.org, xen-devel@lists.xenproject.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Thu, May 25, 2023 at 2:10=E2=80=AFAM Mike Rapoport wro= te: > > On Mon, May 01, 2023 at 12:28:00PM -0700, Vishal Moola (Oracle) wrote: > > Introduce utility functions setting the foundation for ptdescs. These > > will also assist in the splitting out of ptdesc from struct page. > > > > ptdesc_alloc() is defined to allocate new ptdesc pages as compound > > pages. This is to standardize ptdescs by allowing for one allocation > > and one free function, in contrast to 2 allocation and 2 free functions= . > > > > Signed-off-by: Vishal Moola (Oracle) > > --- > > include/asm-generic/tlb.h | 11 ++++++++++ > > include/linux/mm.h | 44 +++++++++++++++++++++++++++++++++++++++ > > include/linux/pgtable.h | 12 +++++++++++ > > 3 files changed, 67 insertions(+) > > > > diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h > > index b46617207c93..6bade9e0e799 100644 > > --- a/include/asm-generic/tlb.h > > +++ b/include/asm-generic/tlb.h > > @@ -481,6 +481,17 @@ static inline void tlb_remove_page(struct mmu_gath= er *tlb, struct page *page) > > return tlb_remove_page_size(tlb, page, PAGE_SIZE); > > } > > > > +static inline void tlb_remove_ptdesc(struct mmu_gather *tlb, void *pt) > > +{ > > + tlb_remove_table(tlb, pt); > > +} > > + > > +/* Like tlb_remove_ptdesc, but for page-like page directories. */ > > +static inline void tlb_remove_page_ptdesc(struct mmu_gather *tlb, stru= ct ptdesc *pt) > > +{ > > + tlb_remove_page(tlb, ptdesc_page(pt)); > > +} > > + > > static inline void tlb_change_page_size(struct mmu_gather *tlb, > > unsigned int page_si= ze) > > { > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index b18848ae7e22..258f3b730359 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -2744,6 +2744,45 @@ static inline pmd_t *pmd_alloc(struct mm_struct = *mm, pud_t *pud, unsigned long a > > } > > #endif /* CONFIG_MMU */ > > > > +static inline struct ptdesc *virt_to_ptdesc(const void *x) > > +{ > > + return page_ptdesc(virt_to_head_page(x)); > > Do we ever use compound pages for page tables? Mips and s390 crst tables use multi-order (but not compound) pages. The ptdesc api *should* change that, but until all the allocation/free path= s are changed it may cause problems. Thanks for catching that, I'll change it in v3. > > +} > > + > > +static inline void *ptdesc_to_virt(const struct ptdesc *pt) > > +{ > > + return page_to_virt(ptdesc_page(pt)); > > +} > > + > > +static inline void *ptdesc_address(const struct ptdesc *pt) > > +{ > > + return folio_address(ptdesc_folio(pt)); > > +} > > + > > +static inline bool ptdesc_is_reserved(struct ptdesc *pt) > > +{ > > + return folio_test_reserved(ptdesc_folio(pt)); > > +} > > + > > +static inline struct ptdesc *ptdesc_alloc(gfp_t gfp, unsigned int orde= r) > > +{ > > + struct page *page =3D alloc_pages(gfp | __GFP_COMP, order); > > + > > + return page_ptdesc(page); > > +} > > + > > +static inline void ptdesc_free(struct ptdesc *pt) > > +{ > > + struct page *page =3D ptdesc_page(pt); > > + > > + __free_pages(page, compound_order(page)); > > +} > > The ptdesc_{alloc,free} API does not sound right to me. The name > ptdesc_alloc() implies the allocation of the ptdesc itself, rather than > allocation of page table page. The same goes for free. I'm not sure I see the difference. Could you elaborate? > > + > > +static inline void ptdesc_clear(void *x) > > +{ > > + clear_page(x); > > +} > > + > > #if USE_SPLIT_PTE_PTLOCKS > > #if ALLOC_SPLIT_PTLOCKS > > void __init ptlock_cache_init(void); > > @@ -2970,6 +3009,11 @@ static inline void mark_page_reserved(struct pag= e *page) > > adjust_managed_page_count(page, -1); > > } > > > > +static inline void free_reserved_ptdesc(struct ptdesc *pt) > > +{ > > + free_reserved_page(ptdesc_page(pt)); > > +} > > + > > /* > > * Default method to free all the __init memory into the buddy system. > > * The freed pages will be poisoned with pattern "poison" if it's with= in > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > > index 5e0f51308724..b067ac10f3dd 100644 > > --- a/include/linux/pgtable.h > > +++ b/include/linux/pgtable.h > > @@ -1041,6 +1041,18 @@ TABLE_MATCH(ptl, ptl); > > #undef TABLE_MATCH > > static_assert(sizeof(struct ptdesc) <=3D sizeof(struct page)); > > > > +#define ptdesc_page(pt) (_Generic((pt), = \ > > + const struct ptdesc *: (const struct page *)(pt), \ > > + struct ptdesc *: (struct page *)(pt))) > > + > > +#define ptdesc_folio(pt) (_Generic((pt), \ > > + const struct ptdesc *: (const struct folio *)(pt), \ > > + struct ptdesc *: (struct folio *)(pt))) > > + > > +#define page_ptdesc(p) (_Generic((p), = \ > > + const struct page *: (const struct ptdesc *)(p), \ > > + struct page *: (struct ptdesc *)(p))) > > + > > /* > > * No-op macros that just return the current protection value. Defined= here > > * because these macros can be used even if CONFIG_MMU is not defined. > > -- > > 2.39.2 > > > > > > -- > Sincerely yours, > Mike.