From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) (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 58C5C284886 for ; Wed, 26 Nov 2025 13:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764164851; cv=none; b=cq5uW2KTQB9SaEButYinWhYTapo0r/RRKIlYstujAU69ccPiTlVCuRCMaUWYLO6wao2YmkOZ8EOKbpB5gALoVUIKrOzJHIAoLNP/npXn5ZiZcyKHnAoJW5A7iNtP9R5Jti/qsVbONgeYKWVoNWEOSDvyajqwmJBeoYYMYh4CrvI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764164851; c=relaxed/simple; bh=nSIeQJafWTiuRYGr2EKztQnParKvqrQ8LRFQDOBk2tM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oQrExGSHsCF2e59AlmnwjycmCc3+vE9GiW28QKPPQ6r2ouZNBx5WviXoDwxOyEPhTHK7CzsxRS1x0WVvZzKXJeHqZUnXdWS0z155wB5iHRL743SgwgjxyFrIrvNi42SNoZgItYNrjpb5xaPSIxXrB2k0N/ykTcEeUpvNqK/XqWY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=kB8wxPZu; arc=none smtp.client-ip=209.85.208.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="kB8wxPZu" Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-64180bd67b7so8908193a12.0 for ; Wed, 26 Nov 2025 05:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764164847; x=1764769647; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=rOcN8utXBvCmBV1D6iZJFhosr0VxKSdczfYTYogMAeI=; b=kB8wxPZulKqm5CMuaISlgzLCj+NijLwmThDZclg9Q7OpUVRljOmHsFbIk2u+72PpLI 39W1IZ1NDvQZABy0V0GNxHaMrpQINWKMeWMQ/RbFd6ILt8Qio9vgOXfqmRHDFo5K0JUo hEm1sMlLxq3MZpMnODWsXdzu3HqpLRWGQmLbxRoSoDRIqUKlCPZrb1IPmI9cpXsHIDO9 qdY+OyoaJpN5lFVYUrevuDOsewKwZkqMW4JxBFXWPwV6m3ttj8nFapHKMeC4eBV4cn0i 9vl9/EjwdaWwAbPdPjVIG2fk6bqGDDiYmteCVwFEkhiEsh42Mq5Q80klejlqWR8ecNvK FU2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764164847; x=1764769647; h=user-agent:in-reply-to:content-disposition:mime-version:references :reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rOcN8utXBvCmBV1D6iZJFhosr0VxKSdczfYTYogMAeI=; b=u04l7fdTdRsF+PVA8s29bqmFg0mqcBwkfpfswdsq80ADEcL2izwUJc9RTSTomwDkLi sq0Lx9/z9+YE51TTsWTX5iHkstWoZ59Ts3DNI7syGLzZ7cdDAxynIfSTwm+eeTpRio4Z zwFapSm30AS/jzvnW/mx9ESzMjokBIUCNQVFj5ddHfE582iVDSeE4uZ3qeEVIwditgUU fBq8u/TAOpQzn+8+MypFqbOISFmME7gcb8al595HAc34OHB9Yp6q+ugKSTSAFvdHtXVu iW9SRkcCKQ07uViWDWoOnEXasvWIXuJnKxSpJVDyI1dZ8ML7A0TTfnYQPB9kdTBQ7KDA sipA== X-Forwarded-Encrypted: i=1; AJvYcCWl6AThrI+JXQ6keQGA6t5vPwq3N1OmZb/iGOqdN2LiVG7O15X0VpOzRobHrSYND0RSC6SR/Tbhj9OnoaM=@vger.kernel.org X-Gm-Message-State: AOJu0YyEGRR1N4T8r5P1MVAukMAlgRVXFD7QCw5yTz6KjMDTvfjhIOrK o7nMZ2AV5bk7Iknox1vofTJgknqfbDS2ByliZ5kTIv5/qd9TVXek2Un4 X-Gm-Gg: ASbGncvfv1qstzyTslPJ4cBJIsQz4jsOSeSvl7yJxEDVvcOtIT3kNfLNaxy5qTc5B0v dTtlYtfLwJYp6qVOpgn42cZaVCVat7XwhqScttzOEdVWKzTlQkUcybFnp+Y4lCcizE/1oPpjHkS dXTdqwconsYY5j87tmECDFPXHeC4v3IVQzocaqFMtZOMrDOaSdYWcoVGglz1zzU/L272nFBM7TI kFeoqR82UpUE844zaET/YOnI2zHV+4hfFVZW6lLMB5jWm0blFkIKBSEQIr5ehXeEFPWNcKHp0BW sbNGnerGMLtkihc2aQ861eMXVsSo6n3G22YHCEU3eHfFfqW9Gvd0t0GIfNNvibruqVlk6g3CMsS zhUyQkSmH6QAtfs7fWB3rQ/JGNMaHZ7ESvjXulXzF1Kb/7E2iCklB5kKaxb3C2i1UBVRMrJsP4v MztZxoH/jUOA== X-Google-Smtp-Source: AGHT+IEHPtR4zyLqNCyvJKPqlt3PqTSeJMo8/BMvDE8703ct4FKH+8I7ByzjstUJPqKt7PJP3sWJCg== X-Received: by 2002:a05:6402:50d2:b0:641:3189:a183 with SMTP id 4fb4d7f45d1cf-64555b99be9mr17506130a12.14.1764164847223; Wed, 26 Nov 2025 05:47:27 -0800 (PST) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-645363c56a4sm17704368a12.15.2025.11.26.05.47.26 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 26 Nov 2025 05:47:26 -0800 (PST) Date: Wed, 26 Nov 2025 13:47:26 +0000 From: Wei Yang To: Ryan Roberts Cc: "David Hildenbrand (Red Hat)" , Lorenzo Stoakes , Samuel Holland , Palmer Dabbelt , Paul Walmsley , linux-riscv@lists.infradead.org, Andrew Morton , linux-mm@kvack.org, devicetree@vger.kernel.org, Suren Baghdasaryan , linux-kernel@vger.kernel.org, Mike Rapoport , Michal Hocko , Conor Dooley , Krzysztof Kozlowski , Alexandre Ghiti , Emil Renner Berthing , Rob Herring , Vlastimil Babka , "Liam R . Howlett" , Julia Lawall , Nicolas Palix , Anshuman Khandual Subject: Re: [PATCH v3 06/22] mm: Always use page table accessor functions Message-ID: <20251126134726.yrya5xxayfcde3kl@master> Reply-To: Wei Yang References: <20251113014656.2605447-1-samuel.holland@sifive.com> <20251113014656.2605447-7-samuel.holland@sifive.com> <02e3b3bd-ae6a-4db4-b4a1-8cbc1bc0a1c8@arm.com> <6bdf2b89-7768-4b90-b5e7-ff174196ea7b@lucifer.local> <71123d7a-641b-41df-b959-88e6c2a3a441@kernel.org> 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: User-Agent: NeoMutt/20170113 (1.7.2) On Wed, Nov 26, 2025 at 01:03:42PM +0000, Ryan Roberts wrote: >On 26/11/2025 12:35, David Hildenbrand (Red Hat) wrote: [...] >>>>>> Hi, >>>>>> >>>>>> I've just come across this patch and wanted to mention that we could also >>>>>> benefit from this improved absraction for some features we are looking at for >>>>>> arm64. As you mention, Anshuman had a go but hit some roadblocks. >>>>>> >>>>>> The main issue is that the compiler was unable to optimize away the >>>>>> READ_ONCE()s >>>>>> for the case where certain levels of the pgtable are folded. But it can >>>>>> optimize >>>>>> the plain C dereferences. There were complaints the the generated code for arm >>>>>> (32) and powerpc was significantly impacted due to having many more >>>>>> (redundant) >>>>>> loads. >>>>>> >>>>> >>>>> We do have mm_pmd_folded()/p4d_folded() etc, could that help to sort >>>>> this out internally? >>>>> >>>> >>>> Just stumbled over the reply from Christope: >>>> >>>> https://lkml.kernel.org/r/0019d675-ce3d-4a5c-89ed-f126c45145c9@kernel.org >>>> >>>> And wonder if we could handle that somehow directly in the pgdp_get() etc. > >I certainly don't like the suggestion of doing the is_folded() test outside the >helper, but if we can push that logic down into pXdp_get() that would be pretty >neat. Anshuman and I did briefly play with the idea of doing a C dereference if >the level is folded and a READ_ONCE() otherwise, all inside each pXdp_get() >helper. Although we never proved it to be correct. I struggle with the model for >folding. Do you want to optimize out all-but-the-highest level's access or >all-but-the-lowest level's access? Makes my head hurt... > > You mean sth like: static inline pmd_t pmdp_get(pmd_t *pmdp) { #ifdef __PAGETABLE_PMD_FOLDED return *pmdp; #else return READ_ONCE(*pmdp); #endif } >>> >>> I find that kind of gross to be honest. Isn't the whole point of folding that we >>> don't have to think about it... > >Agreed, but if we can put it inside the default helper implementation, that >solves it, I think? An arch has to be careful if they are overriding the >defaults, but it's still well contained. > >> >> If we could adjust generic pgdp_get() and friends to not do a READ_ONCE() once >> folded we might not have to think about that in the callers. >> >> Just an idea, though, not sure if that would fly the way I envision it. > > -- Wei Yang Help you, Help me