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 8C9B23E6DD4 for ; Mon, 8 Jun 2026 19:43:39 +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=1780947820; cv=none; b=b3ePUsZnb3xFfeLn68C9cYkAsAjH0iuaN0OujVfRJETkz4lUbDwCzMeyAUQ7Eg1uJtSEolTYRPRO5o8AmVBwf72lOz/3esDFBzwmvLNKs1vg5N3PVzKUmEy6KZOzQ2o5+5R2J56dZ+M98gTuHb366f+2N/WU4Nc5w+BpJqCXfIc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780947820; c=relaxed/simple; bh=etrKXcFBMen5TXae63L9aHdVuHYxLJofSqP/JQTAbh4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b/oFqgfrFVcnNm+hSnlDhiF+lJIttzWZgju7axxaSnETrF8pwzD3mzkssW+zi/L9Ek61IzrQOyZNnC9b7rGifIrA2joSm1DEhC19Rdt2xbz/nHiv6vAOZZ0zfxnr3zQL6AVne5L1nQGwK65mrd4Tn0ZHvPzz5DzS7iD1er6WDxw= 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=NBFzDcyn; 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="NBFzDcyn" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-8cd45d4b7e2so55395006d6.2 for ; Mon, 08 Jun 2026 12:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1780947818; x=1781552618; 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=Kn5+ZpQefRkmWKbevzDNoMTNeOUuJtiAWUOcjYbKJkI=; b=NBFzDcyncSmbs31td7ac8URCim7kgErghiGAuX7Y9fXrAzYWI+rkzcjHti9DAgeaTZ w9wEykOawzjFQ0KkXVHyIoKYZIE/k0CmV8zGymEeAVMf0BoiNvQ+ro+Y1ctNN2txAfZE phCGEPqtP5JS28VWFL5b89T3DHsJDiDrXnnA3VrUphxoVgmpCjOWoraAaNlxnG9RP1pr 121TEskReUEkqOboDQi1cbOCp5TO/Vtg+pWTdfZGGGpzKv5VzIsOsji+CjNKSojxA/MF MQBCeekXZCNfx1jooMA8KAafCi4j48DLFcDaRdUVAGP9ooZsSxdOE5RtWdkd+6aqjIe+ oqGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780947818; x=1781552618; 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=Kn5+ZpQefRkmWKbevzDNoMTNeOUuJtiAWUOcjYbKJkI=; b=rEYxE/hRi7+4nXy8GzAQF7cMlKtwrNS1ZP+LpGH6bcn7tGFZG0uFm64WKM6f+EllzS Z7iMiT9nJhia/pP6+9CR2/oyazMv5NlnUWqZob67hP4kNatYbfg1amgbnP/6L24VQ0Wa 3R4QrYo1qebr2wwNtj3l+jqpRr5+WXDJKZRI14oq0h3oNigI31rdqnK6BfEpWtSYJMTx 3NBjCIVU83bHvquZTTQttgxtFVS/r74i8cevwFe9TGkCpDk7Bf7GAE0oFrnpk5i5vsr3 O2Y/YKsyKqvcm8MAfOTNB7Wpp/uZao8u7RbBb66tMrQQaZZhnEqgwMcuYFJEVAJIPmVO R/Sw== X-Forwarded-Encrypted: i=1; AFNElJ+z2JheZhYE6sdmZCNjZD0DB/Ortk3oSIU1Op4plQyx7ZApwexpYvy6o3wKNrJzYyGbnuWDlQDabyV2BTs=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1eJ9tjkf42oLnl73IBdQ6KxQoeilZcYxeP8QiuLxC9Z6BcPeL PQxVOb+7pAO2g66EBc/Kre4IPhCp2ho2YR+tTcqS1QkgGTv1JjHVAuwTVxbkvsmKZtk= X-Gm-Gg: Acq92OEkmm8TzUVe8O5nskaN/x+uAEjqXqqeiDjMJFNiwf5o+SM6wyDz8J9SE86Oq91 JJ57a3N6T88cSe0VJhozDTFkMVg9w/GJAQbTgrA/Y8N3aPrYisNaN4eiup+vu5KZm90AtiB0IRQ uW78PgPSmWx5HIXEo7G5M8VhyLqJ3W41DHYn/5jm7TMaWyXaxlWdZDVGduNO31ngUUJYmGCVKnn 8Etm6DmanAecH4f71+uNG5+ci94WxyrZqJy9A+44yh6dfCN9BdgFnAGL0zNUwwZFXj2du7gBGKv HI9E9bbMnLZ0w3QLHHzFKQs1sWik1V9POPQCMz5FrTux8CBkaKzFtTjqsoO8poyjuSYHpZbEl3Y 7li5UUiZyglBnTY1hEOFSDWmGVBHyRYydjnHqsc2+4dsHb5LvTHE1almEDwIgJuDs2Z+xepbZzQ gQTS/g+psG+eFRW0h/ANMPWMJDbSbxKAxKuvgBmKYeYsVWBvfgJg94rrKTjmeeSWoJlQdngn+od nr0uIG93s7KfzC+Kg== X-Received: by 2002:a05:6214:2c13:b0:8ce:b018:89e1 with SMTP id 6a1803df08f44-8cee628fefcmr267968686d6.32.1780947818366; Mon, 08 Jun 2026 12:43:38 -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-8cecd07629dsm176866096d6.39.2026.06.08.12.43.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 12:43:37 -0700 (PDT) Date: Mon, 8 Jun 2026 15:43:35 -0400 From: Gregory Price To: "David Hildenbrand (Arm)" Cc: Zi Yan , 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> 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: <2475e4c4-9ba3-4091-9bfd-1c1c15163da7@kernel.org> 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. We seem to have agreed "yes", which necessitates the plumbing of the address into the allocator. The question is whether it should churn the existing interface for have its own explicit interface. The implications of getting it wrong are: a user page doesn't get zeroed. *oof* I think that's why we thought the churn was better. But considering we're already in the same state now (callers are responsible for calling folio_user_zero() or whatever), maybe that's not horrid? ~Gregory