From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (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 BDF1F33554F for ; Mon, 8 Jun 2026 20:25:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780950314; cv=none; b=kQQbeFVgQSn9DacSnSdK9/zbC5lNPEnQYoAK4dQADm/LhQs68pHUu0alUhJS+/XW+to58As+SBCJr9h6OyC05YBVDlBh79lawxIPSb4pmg+sczEfl6t3Ys8UNHYlfG5L8pfHe3e6ePuzWcwjzKpvcnN+r70G9+iN1zlCTz6V3qA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780950314; c=relaxed/simple; bh=ImfI2N5lsSbY8ZIrrjW/GdrRf15xOOnh5SqHf/0DTwo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XEkcQG3NDaos8LWz7S4Bfhngm1/RooGzCnUtrbKIZVs0UuNfmZMzerWwozEWbz+FJ8DIOnmLUkFEGFQzxO2Bh2DOMVjuuLT4Wb/OnCjYY+JUDkO9nUa91Ch/r2D7BN86d2YEIqv+74dapc/hvXHUJzt/wSTZUpNNBiBIBKIrI/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=UCCJ0Luf; arc=none smtp.client-ip=209.85.219.49 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="UCCJ0Luf" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-8ce9ddeddefso52971636d6.0 for ; Mon, 08 Jun 2026 13:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1780950312; x=1781555112; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7CLdOd3zAkOhu7t1Gmww+B7T7VImh1oQ+8y8VHy5V/0=; b=UCCJ0LufKPLthwX4erXVYhdApK8R4gjsoCP03fC9v9HGgj1QgaYpvwbCqdTPlnR58X 1Kh6xp3fCBteDcRAMbmPLZjQsoC4EnwhEp2hBFkEplCncMV0eNiQHPBNXm/8oQXBzBR0 0K5cWfbtIjMYMEDKXXmIsu/UxBH7ALFkUo5U2Gg0GsTcZLq/UGdajCWK1nH/KBkx8hYM /9bQG6uRRv8Wa2KfwT2Wgiu7xU64XSYO974RK/HEEbUCRg3CPkl7Vpu8K4lBK5iKcNzV Q8yRnTK9rwfJoG07ZP+TngZWRjffw9CL5hJz/2ELoPs8ifC13zjNJi6w7T1EoUKOEy3N WjxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780950312; x=1781555112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7CLdOd3zAkOhu7t1Gmww+B7T7VImh1oQ+8y8VHy5V/0=; b=IO39Mqcx9qA3EAIB0vb24iSQp7w6UrB5IXi73+vD5tGshelb/USrBtK3Gh2yylJjtg 3U4xieZywYD7vc6cGm8SeMNnXWDbPd1PyUo6lmpoL6LBXo/dsIUkKgkOzK1K5enfAlmr zF+KX8BUrvYaCVNHKMQoDF670pKr6VyjxBelfT/HXVxKNyqaNM0MMCKtkPG5755WSQPL 8mWIqOqkFajlLfqsNaLBPUG5FyRIenQwx+C8gkJ43E3nWzvirJ9vXT1fwIcgKOobpJ/Q Syxk13izd2s3AlzBJ5v5dRntgPQT6TutbjqqsY3ce/XT5B/uxoN1Xc4ECvUy3bHlRdpS wSLA== X-Forwarded-Encrypted: i=1; AFNElJ9SJEUtChV57JzZlYIaZlIL0tNNlYLz/Ze2Euj1S/YCveHL5fJmrNoJs/ZYR6nSDOcHY3O020cQZw1JWWM=@vger.kernel.org X-Gm-Message-State: AOJu0YzhQUrkHg3soJM18rtEljTWsIZJeVYC1u/DviWU+Flk1ZouKuZE 33f+KcbjihhUbExFMSBqvvT2t5p5pXGdVWdPktiUXiMfw+QYrDOqA6rDNhGbJa23Qcg= X-Gm-Gg: Acq92OFWqhK+qDaYPb9wyzNVrR4JGpKiYBaOhWV9xr7IXNzPCPsVS2ToJl/P3Rjxe1o 3npTcTacYzPtFlciuZaxa6XD5+13FEfr3n3ShVDBeC+8Ptc+8sFjIygElScp+AFS6P4rMx3sg3V R67vBXjhXNP8jsNQs6R4kzLgTff+B9W1VM+Nh3xt7hYlqZa4xfFLNEwQ1xRXS6BBHT6aFCmD3Ui 3wANkKkPvWLFZmxBsQjGrWT6V0zMTbaFlFag2wuYb8FI81nH858kmEFqWdvxf7fyjVXsitpnLWb 1C3u6U1db4Lhmw2/rqJj9zDefLNPs9wRwvWL3i0F+FIYR883vspMEqQ0B6oOlv48lU4PrlOyyAP PX3WDoBx7tjMysbeMxCdHmUq+Wfite9QaOOay1gnEbXDveLI+8cc2AMC0Sar5Umt0iKfYrsyIC3 u5KUOYJbJQ3Im8VIWrhIUUBzVbkJJrOdaGG4ShrDxe9XiE+TxF4n3DxXRjpqjaqtfydsCn2HYvI 6d1tLeN9tKt7brJZA== X-Received: by 2002:a05:6214:2aa4:b0:8c4:edb4:a44a with SMTP id 6a1803df08f44-8cee62657aamr283094386d6.23.1780950311379; Mon, 08 Jun 2026 13:25:11 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8cecd0520d3sm177019896d6.27.2026.06.08.13.25.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 13:25:10 -0700 (PDT) Date: Mon, 8 Jun 2026 16:25:08 -0400 From: Gregory Price To: Zi Yan Cc: "David Hildenbrand (Arm)" , Lorenzo Stoakes , "Michael S. Tsirkin" , linux-kernel@vger.kernel.org, Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Hugh Dickins , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , virtualization@lists.linux.dev, linux-mm@kvack.org, Andrea Arcangeli Subject: Re: [PATCH v10 07/37] mm: thread user_addr through page allocator for cache-friendly zeroing Message-ID: References: <50d410b47fe3f45327783e05bd306d5eaab75e65.1780906288.git.mst@redhat.com> <64f2e580-aa82-4849-9236-b8ec4208ca24@kernel.org> <2475e4c4-9ba3-4091-9bfd-1c1c15163da7@kernel.org> <8BB8D6E5-8644-4CBC-BAF1-0AA19702E042@nvidia.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: <8BB8D6E5-8644-4CBC-BAF1-0AA19702E042@nvidia.com> On Mon, Jun 08, 2026 at 03:52:20PM -0400, Zi Yan wrote: > On 8 Jun 2026, at 15:43, Gregory Price wrote: > > > On Mon, Jun 08, 2026 at 08:39:10PM +0200, David Hildenbrand (Arm) wrote: > >> On 6/8/26 17:27, Zi Yan wrote: > >>> On 8 Jun 2026, at 7:08, David Hildenbrand (Arm) wrote: > >>> > >>> Or should we defer zeroing after a page is returned from allocator? So that > >>> user_addr does not need to be passed through irrelevant allocation APIs. > >>> Something like: > >>> > >>> alloc_page_wrapper(gfp, order, user_addr) > >>> { > >>> page = alloc_pages(); > >>> if (gfp & __GFP_ZERO) > >>> clear_page(page); > >>> } > >>> > >> > >> Not really sure what's best here. I think we'd want to limit the lifting to some > >> internal API, so it cannot easily be messed up by random kernel code calling > >> into the wrong API and not getting pages cleared. > >> > > > > We're a bit in circles on this. We discussed explicit interfaces a few > > months back and the trade off was: > > > > a) add user_addr to the existing API and cause churn > > > > or > > > > b) add special interface like above > > increase the buddy surface > > leaves open the ability for users to get it wrong easily > > > > If we forget VMs for a moment and break this step out separately, the > > core question is whether page_alloc.c is the right place to be calling > > the folio_user_zero() or whatever it is. > > page_alloc.c calling folio_user_zero() is fine, but my question is > whether we should do the zeroing inside post_alloc_hook(), part of > allocation. > > What I propose is to lift __GFP_ZERO up as much as possible, > so that most of allocation code does not need to care about it. > We do the zeroing right before the page is returned to callers. > essentially we end up with something like alloc_frozen_...(..., gfp) { folio = whatever(..., gfp); if (gfp & __GFP_ZERO) folio_zero(folio, -1); /* don't do cache flush part */ } alloc_frozen_user_...(..., gfp, user_addr) { folio = whatever(..., gfp); if (gfp & __GFP_ZERO) folio_zero(folio, user_addr); /* do cache flush part */ } The downside of this is obvious: it's easy for developers to get this wrong and call the non-user interface for user-bound allocations and miss the cache flush (that is only needed on some archs). Not saying that's a deal breaker, but it's something to chew on. ~Gregory