From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BAA1542FCDB for ; Tue, 28 Jul 2026 12:03:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785240182; cv=none; b=RgW+ICc/A9oEYGPNTLTlavJP2jOIn9AV+SZ4RjzR1/0lJvWoTise5e+3QaweuNK9FOSEZ8azPIKk4u1ts9t4sdWH6fUpf6K64xsT3C3ZYIv56fsjgb3gYT2l25qm9RWqfHVF7zy+8WF9bT5gu9JNnUdV2I62khnW3O1nc3iHQdg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785240182; c=relaxed/simple; bh=g0p9K5D5p48d+ddjtkulATG91igJ/A8UwS+PVeydJ+g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l9fUmOcgWpIKUHh9NwYHGdU1Tpsx0Ts0BDUySwj35acN0NReGM+my1IgyLeHdaIMqvJ0yLlBoNGdmQoYH8IZ/u+s+59NpiFVB/8+DXSfSxvJK+RXWOtthqsx5YgknobXGYPEeJURIE8LbOkMLX0MeL1jLxZGAvcS9VCz0OqPkAE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kJT3l3QX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kJT3l3QX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 230131F000E9; Tue, 28 Jul 2026 12:02:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785240181; bh=ngSI3Q4vIhFKWjmDx5jZEvBPeOv5VUXzzg0prABQgHM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=kJT3l3QX0SOCL0bfIt294zpl70CdxnCDhs43jrRz5jlxB5zOfFptE41eAqWlCMn8B pfsuwwn1vgSr2MObaC2UlPqlj6Z8RSdDJMA42cAiRnkYhLCquk0hvu1A5SLuRkKcwW x0UAdTzr/a4HRssfbPQA0+RQV2Zgc+AShibCbTRQ4V7hBbUSCnwEjaLUKA6kkjcP4h jJz7VDcmINqhx3QHd5Z+6FXUek2qTlnb2K9dGhL/ckYlVqgJxrLWngwxP1pnNqHWok NcSA8mYorOqBkGj6uPp2dKvdujI5hjNkaFzA70ytIz0gRBiSDOwXiq5aVCYnVDZ/Jo EdM1gq39lqYmg== Date: Tue, 28 Jul 2026 13:02:54 +0100 From: Will Deacon To: Wen Jiang Cc: akpm@linux-foundation.org, catalin.marinas@arm.com, linux-mm@kvack.org, urezki@gmail.com, Xueyuan.chen21@gmail.com, ajd@linux.ibm.com, anshuman.khandual@arm.com, david@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, rppt@kernel.org, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, Wen Jiang , Leo Yan Subject: Re: [PATCH v7 1/7] arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup Message-ID: References: <20260715120813.3609949-1-jiangwen6@xiaomi.com> <20260715120813.3609949-2-jiangwen6@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260715120813.3609949-2-jiangwen6@xiaomi.com> On Wed, Jul 15, 2026 at 08:08:07PM +0800, Wen Jiang wrote: > From: "Barry Song (Xiaomi)" > > For sizes aligned to CONT_PTE_SIZE and smaller than PMD_SIZE, > we can handle CONT_PTE_SIZE groups together. > > These additional sizes are mapping spans used by non-hugetlbfs(vmalloc) > mm code, not new HugeTLB hstate sizes. > > Signed-off-by: Barry Song (Xiaomi) > Signed-off-by: Wen Jiang > Tested-by: Xueyuan Chen > Tested-by: Leo Yan > Reviewed-by: Dev Jain > --- > arch/arm64/mm/hugetlbpage.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c > index a42c05cf56408..7ce159483a354 100644 > --- a/arch/arm64/mm/hugetlbpage.c > +++ b/arch/arm64/mm/hugetlbpage.c > @@ -94,6 +94,11 @@ static int find_num_contig(struct mm_struct *mm, unsigned long addr, > return CONT_PTES; > } > > +/* > + * num_contig_ptes(), set_huge_pte_at() and arch_make_huge_pte() can be > + * used by non-hugetlbfs(vmalloc) mm code to set multiple huge mappings > + * at the PTE level. > + */ > static inline int num_contig_ptes(unsigned long size, size_t *pgsize) > { > int contig_ptes = 1; > @@ -110,6 +115,12 @@ static inline int num_contig_ptes(unsigned long size, size_t *pgsize) > contig_ptes = CONT_PTES; > break; > default: > + if (size > 0 && size < PMD_SIZE && > + IS_ALIGNED(size, CONT_PTE_SIZE)) { > + *pgsize = PAGE_SIZE; > + contig_ptes = size >> PAGE_SHIFT; > + break; > + } Under which circumstances would you get a size of 0 here? Given that you're relying on arch_vmap_pte_range_map_size() to give you a well-formed size, why isn't if sufficient to check only the alignment? > WARN_ON(!__hugetlb_valid_size(size)); I agree with David that it's messy having hugetlb tangled up in here. It means this validity check is now going to miss some genuinely bogus cases for the hugetlb path (as opposed to the vmalloc path). Will