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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E57CC54798 for ; Tue, 27 Feb 2024 09:15:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9326094000C; Tue, 27 Feb 2024 04:15:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E1A2940008; Tue, 27 Feb 2024 04:15:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7AA5B94000C; Tue, 27 Feb 2024 04:15:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6726C940008 for ; Tue, 27 Feb 2024 04:15:21 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0D4961C0CDF for ; Tue, 27 Feb 2024 09:07:45 +0000 (UTC) X-FDA: 81837006090.04.FBE537D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id B84DD180026 for ; Tue, 27 Feb 2024 09:07:41 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709024862; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I/ib/Yn97ZPBnQQc3bZ8x17hr+B1ulRaPWcGWCBwwFw=; b=ODgs7vE1PpfrGhy8vbOoZDT/fHVmde0UdRGyWG96g1TTeS4tBZvgaoSCkHSJGtMm/iBIMy yZjRaelqF0sV7h3TAuDpdnAlcKgG6YEewO3m64KCaysoBxXKCYjTWHIVqjMvGWcYXbCzzP 6W6YTaYo45A0ErIvY52UQ0zsjRmdr6E= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf24.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709024862; a=rsa-sha256; cv=none; b=7RH6fuzT+6W9i/FNF46dfHf7qbr/iXxnrwK0KKBfAzDRC+qdGHiOkL7ajZCsV6TVim7bB/ etjRdZo4IIm5On5aWETZqpuxNOrR8kVo1fZ5Y/bTBI3O30DxgWj1QoDQLfHzMSzxT3Ie6P iFb2PLX0T3tnlu3b6AwCsWfX2an8qp4= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CF50DDA7; Tue, 27 Feb 2024 01:08:18 -0800 (PST) Received: from [10.57.67.4] (unknown [10.57.67.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EDF053F762; Tue, 27 Feb 2024 01:07:38 -0800 (PST) Message-ID: <61b9dfc9-5522-44fd-89a4-140833ede8af@arm.com> Date: Tue, 27 Feb 2024 09:07:37 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: export folio_pte_batch as a couple of modules might need it Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org, Barry Song , Lance Yang , David Hildenbrand , Yin Fengwei References: <20240227024050.244567-1-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: <20240227024050.244567-1-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B84DD180026 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: nyygdg9ynee7uqueaa3ombxaky4e63so X-HE-Tag: 1709024861-114721 X-HE-Meta: U2FsdGVkX19fSoLTos3Erc2G1L4y8XhRAKFW2Io9qnVoJ6AtYvAD+W/2aO8jnySWeSxOAlTjXXRIeYsB69G25y3BBbBZTCejHIfNZUx3XmIDTu1bqcVFcFnJjdtJ3db/M0vjeSuCkf7Czj3XYMIYr6x7TnXrX02CaRoV/Eq9QaWTFxD+iHP5B0/vjSmjXLLZFu/ygkNLikOYsh0lqzppB7U1nQzQG9ux26jHClESyHplR6DSejk1JGGr30YeHsPOJih9m0klv1vpwJJO0RagdKT/Gll1uxhD3pGgCNV2sp9wbHLS1f/UvSoAhFly7Mkr6P7UIyHgpZDFh5nDTWZwdmE3jZ48vVlidSDkpytmr4Bh8WqwlJUUPyxLvpBPEqjbvfuHK3H95bGowYXhwLhisma4XLqJtbnx7bWACoqOAYmXqWjt2CkZnF2U3JtPBymOF+cnKQOVZqGcAe1ieI4ke54d4rjuAMXf5w08z8/mI67Ph2M75azrKgdRxeaExtxXYx1l7I0zgmUW3l3WNm6B7i94hlXK1PKt0TIby8+C+m1NExgXpaE5LqxYpC767gHOsbws6kEcvzYuYkJyKyOpLfxSULck17ObhpTwiDbwRHNKwHBjOa+6r5+tDEe2HqPd6o4CaLYS/uXHm70fFPXf1rdW499ucxOB7YfUlOpb758WSFDkYBWFZ9nPMPqkPG9a7pfsLx8WchgFutF3fCZitMTkKBVPY4ojmcvto2ZPaiI9n6yuRnisjRLkWUBm5SPPCB1M4qq/+6eU2HUCLxgC6QemuGB1Is0EjNasx2UDHhpKz1+gM5x0BSxKV+4tQcx8JsFmkRrAz69iseUrM6x13q/Yo0Z9X43tl1niYWV3rRtESLL687yjb0eDX3O+8Jv291aAHgaZ8xm0nnkZM5VaAIg+pzHd9ZryiY3n/ka/iFVx6DPb7JRQycdkZmjdJTWqXxiBK8lvBzda4YxdwGi KKR8lPKn qozjFnW8Y/ZP57Kd3dPQKfS+qdVe6KR05+OAt8aQiCwAwRrC9ctXt+D4cTQvwlscQq6dvV0qvLb8na9JTzCXPrPp2Xwr/MRIaiCli5XZ+QjisU4xC0DI4BF0RQddbaEKSnp6ys7chA/VtPi/reokYhi1HxTVmqabOtBSzA+02vj5BZT+lzbvz5ApmWcxUmLVpO5bI83CgqeCYuCxYMgfU3adDx3MgH5/e+H6KqJp2kiWoTouNCDDgDHGrfyreIGjkvFVmwjxNzHc1fPrgWzjav351dBisKbHMy1KgwHl9ZKgeS9tHMhZZzafQE6/j3M7E3aggX3tFyD4r7OjArsiuHFIBCTFF91Nk6xNZJefYZMcDUOGskeN/6cEDSYlKze5rv1JaDNnglYiY6k4J3ZJ4LVhaZ8Idpk6Th8K5wru2WQVquSy0PP+Ll7xvzvGKoYbEjLMo X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 27/02/2024 02:40, Barry Song wrote: > From: Barry Song > > madvise and some others might need folio_pte_batch to check if a range > of PTEs are completely mapped to a large folio with contiguous physcial > addresses. Let's export it for others to use. > > Cc: Lance Yang > Cc: Ryan Roberts > Cc: David Hildenbrand > Cc: Yin Fengwei > Signed-off-by: Barry Song > --- > -v1: > at least two jobs madv_free and madv_pageout depend on it. To avoid > conflicts and dependencies, after discussing with Lance, we prefer > this one can land earlier. I think this will also ultimately be useful for mprotect too, though I haven't looked at it properly yet. > > mm/internal.h | 13 +++++++++++++ > mm/memory.c | 11 +---------- > 2 files changed, 14 insertions(+), 10 deletions(-) > > diff --git a/mm/internal.h b/mm/internal.h > index 13b59d384845..8e2bc304f671 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -83,6 +83,19 @@ static inline void *folio_raw_mapping(struct folio *folio) > return (void *)(mapping & ~PAGE_MAPPING_FLAGS); > } > > +/* Flags for folio_pte_batch(). */ > +typedef int __bitwise fpb_t; > + > +/* Compare PTEs after pte_mkclean(), ignoring the dirty bit. */ > +#define FPB_IGNORE_DIRTY ((__force fpb_t)BIT(0)) > + > +/* Compare PTEs after pte_clear_soft_dirty(), ignoring the soft-dirty bit. */ > +#define FPB_IGNORE_SOFT_DIRTY ((__force fpb_t)BIT(1)) > + > +extern int folio_pte_batch(struct folio *folio, unsigned long addr, > + pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, > + bool *any_writable); > + > void __acct_reclaim_writeback(pg_data_t *pgdat, struct folio *folio, > int nr_throttled); > static inline void acct_reclaim_writeback(struct folio *folio) > diff --git a/mm/memory.c b/mm/memory.c > index 1c45b6a42a1b..319b3be05e75 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -953,15 +953,6 @@ static __always_inline void __copy_present_ptes(struct vm_area_struct *dst_vma, > set_ptes(dst_vma->vm_mm, addr, dst_pte, pte, nr); > } > > -/* Flags for folio_pte_batch(). */ > -typedef int __bitwise fpb_t; > - > -/* Compare PTEs after pte_mkclean(), ignoring the dirty bit. */ > -#define FPB_IGNORE_DIRTY ((__force fpb_t)BIT(0)) > - > -/* Compare PTEs after pte_clear_soft_dirty(), ignoring the soft-dirty bit. */ > -#define FPB_IGNORE_SOFT_DIRTY ((__force fpb_t)BIT(1)) > - > static inline pte_t __pte_batch_clear_ignored(pte_t pte, fpb_t flags) > { > if (flags & FPB_IGNORE_DIRTY) > @@ -982,7 +973,7 @@ static inline pte_t __pte_batch_clear_ignored(pte_t pte, fpb_t flags) > * If "any_writable" is set, it will indicate if any other PTE besides the > * first (given) PTE is writable. > */ David was talking in Lance's patch thread, about improving the docs for this function now that its exported. Might be worth syncing on that. > -static inline int folio_pte_batch(struct folio *folio, unsigned long addr, > +int folio_pte_batch(struct folio *folio, unsigned long addr, fork() is very performance sensitive. Is there a risk we are regressing performance by making this out-of-line? Although its in the same compilation unit so the compiler may well inline it anyway? Either way, perhaps we are better off making it inline in the header? That would avoid needing to rerun David's micro-benchmarks for fork() and munmap(). Thanks, Ryan > pte_t *start_ptep, pte_t pte, int max_nr, fpb_t flags, > bool *any_writable) > {