From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 683583EAC96 for ; Thu, 23 Apr 2026 11:57:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776945437; cv=none; b=Sl8H+qAgE7tTPz2hr2d2m/VAkbtoB2QQl0jIcdkrKEah8QFNfI1xeV85WnaIETGufWjgr4tj2PaX5cx6Ep/Cc50T2PV5vCTZB3sKbpUqyF8lWDKpMemRNGZpQ7GQhTdKECvhf52DAHLHMG1zfOI5GIgO2fUKZT4uy+SzGK57qKA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776945437; c=relaxed/simple; bh=cerLyyGsxZbpGHR7Ohl2x/Kc4s1l02lVCZCqTvZs2Qc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p0umtlkH9D0+2uCdsJ8Hd+svXmK1o9vv0Mde/OPR9WC6G4NtespeObqFxGJrV73Pi9/2ImwqxVKmwfEosY7UA80X2f9UactJA2++U13FGydEMKkxByXVISNSV+F28s73OHSMo7uwGVF8vtI+lwO1QGUbLqamaUQBFa90WYJtJN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=idkCZOup; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=bANPhGir; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="idkCZOup"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="bANPhGir" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776945434; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jMZWtfjIWNO/JysIhn7eMR9XhBiqbQQjvoPhb55A6AY=; b=idkCZOupGtbKqjmqoVCIoASSbzm3/wKR59tOKjC06iHVMRUe4EjFmBm3ED+8jYe+8M4NHE 8syu1xEMbZHyeOILZUJbYnpqdRjPJolLBZ/073/Xrvgh8XY/rzEK5+wyfNej2UtKUx0AdM V6bfPyetYn+HSyXGNFc3wsbF5en4uOw= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-381-9cByDO1dMwan95A4vS8WMw-1; Thu, 23 Apr 2026 07:57:11 -0400 X-MC-Unique: 9cByDO1dMwan95A4vS8WMw-1 X-Mimecast-MFC-AGG-ID: 9cByDO1dMwan95A4vS8WMw_1776945430 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-486fa07f2bbso47426945e9.2 for ; Thu, 23 Apr 2026 04:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776945430; x=1777550230; 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=jMZWtfjIWNO/JysIhn7eMR9XhBiqbQQjvoPhb55A6AY=; b=bANPhGirsmlR4qb66ZEyN5QWn8HN0xQItm0pxR1mWwTuzsiB2jbiV5pSl/ZF2X5dDh g2uqVIOCGpqA64/b7soZjiX2wjb8opGxQchvI3Dgzil1GvmeKr7R/Py9e4pNV1yP/vh0 vq07s2lFJ5hbArij3YJCBj00t19O02R+vy2ofHNn4wNGSC1PhTUN57K3GI6kpvlUSJzJ yvv6HSYtdQCDUxtCHeAeXMLPL/XdjjpSkU0Vh42vHH9qX4E2fDGfI/14wTl0FI8YfnE1 iZnU9X7ckTZGkdPm//jIBbYzhFWyEfCiekDLtpANsToydffHVXdPQNufcZYuOUTeBa+2 uAyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776945430; x=1777550230; 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=jMZWtfjIWNO/JysIhn7eMR9XhBiqbQQjvoPhb55A6AY=; b=InnDxW+qJlngfDzlgyjqk3vUFhDnuiTKjrGZZCPogpnXOoenCuvw4D++JvUHmFeTNi BAWcec4vVwOhX2MDhzEdeRImFr8H5TUrZKgHk59NaXM0Y1jfN8WTw4wDbQb4P2IjYWgz cs7ot/HLNTDTbLhOHlEP4qh7qIa23ZL5OZbrF2yCVSksZoxujVE3QfsNNyQXDAI9oEXF /pVidoRBl8HBTSFsQsd7SEUJeH9foDomrXVwUFy9S9E002PaAZFJPVW2yMac2tDfGh8U McrMtI2tw9Hc4xhWM+0TwBAfTZdvFd3JrRpynfqbyXsJbW1QJa9fNDgI13VSAJ02XswC 5JfA== X-Forwarded-Encrypted: i=1; AFNElJ+tI8DQv2MwMeM9kOhg9K6gvhvtZWp3Haq54jpF7+oXP+HKCEZMgnTQW/KStO95mTPT89268Dm7aC3S4jc=@vger.kernel.org X-Gm-Message-State: AOJu0YweyIDrm19J9ZzLak+gbpU7GIX7PzEsohXPDkOcFpH0cBOLyMrA Z5Mx+EW7esYXK6TwjJtJE2/254mhUBfIkR6xBw6HqilvPahq/CmOvge8UZ/vmtc3gRXbfdJUUrD 2IlLMQULLnLZt5XCS7kP5PDJjRKSuNo+8E2MuuJxtZa0YaM7t6zZCZFB61Gbp4UfAzw== X-Gm-Gg: AeBDiev6UPu9IObUf+JPeqsitp2E7pYNadyOfMt3nyPgXYPYUoGl+Mii7ccTm+6tzY5 hmCDDwVbibwckfFExyKxPPbjpm+F9E2PAWMnVSlD+H3KUjdSbuQJxsSd8J/WBBZYIBCvBLKBXY6 gt1uec/zLytwyY+lrFEkwL7ESnJYNOBry85WSiavcjzkdPjbZUGDdWrBFBTZKnRfZVMdqYdq6NB iPImqaBRelKiN/hqOUxLJ1ylXLXG6wMImHckTZT0OrgaHGPtdf/jkRNC4QPFv+Fn2gCLHik2e5z UcT7KM+8XYFE2HaSEA7fnxYe/4klaiz/DH8r3k+l3hXuHae+MLv9em72hpGjF1896s7noLkrkrD ASeNGxCGc/LGyr22rKZGtumOKY3kzztklz0/u3koDf/gzLR71kBY5+Q== X-Received: by 2002:a05:600c:8b4b:b0:489:1ff1:74f4 with SMTP id 5b1f17b1804b1-4891ff17707mr203280015e9.4.1776945429714; Thu, 23 Apr 2026 04:57:09 -0700 (PDT) X-Received: by 2002:a05:600c:8b4b:b0:489:1ff1:74f4 with SMTP id 5b1f17b1804b1-4891ff17707mr203279475e9.4.1776945429042; Thu, 23 Apr 2026 04:57:09 -0700 (PDT) Received: from redhat.com (IGLD-80-230-25-21.inter.net.il. [80.230.25.21]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488fb7bf7besm184344495e9.34.2026.04.23.04.57.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 04:57:08 -0700 (PDT) Date: Thu, 23 Apr 2026 07:57:01 -0400 From: "Michael S. Tsirkin" To: "David Hildenbrand (Arm)" Cc: Gregory Price , linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Brendan Jackman , Michal Hocko , Suren Baghdasaryan , Jason Wang , Andrea Arcangeli , linux-mm@kvack.org, virtualization@lists.linux.dev, Johannes Weiner , Zi Yan , Lorenzo Stoakes , "Liam R. Howlett" , Mike Rapoport , "Matthew Wilcox (Oracle)" , Muchun Song , Oscar Salvador , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , Hugh Dickins , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , linux-fsdevel@vger.kernel.org Subject: Re: [PATCH RFC v3 01/19] mm: thread user_addr through page allocator for cache-friendly zeroing Message-ID: <20260423074433-mutt-send-email-mst@kernel.org> References: <9dd9deabd42801f3c344326991d1431c3d8db39d.1776808210.git.mst@redhat.com> <20260422171315-mutt-send-email-mst@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: On Thu, Apr 23, 2026 at 11:46:56AM +0200, David Hildenbrand (Arm) wrote: > On 4/23/26 06:31, Gregory Price wrote: > > On Wed, Apr 22, 2026 at 05:20:27PM -0400, Michael S. Tsirkin wrote: > >> On Wed, Apr 22, 2026 at 03:47:07PM -0400, Gregory Price wrote: > >>> > >>> __alloc_user_pages(..., gfp_t gfp, user_addr) > >> > >> With a wrapper approach, looks like we'd need something like > >> __GFP_SKIP_ZERO so post_alloc_hook doesn't zero sequentially, then the > >> wrapper re-zeros with folio_zero_user(). But then the wrapper needs to > >> know whether the page was pre-zeroed (PG_zeroed), which is cleared by > >> post_alloc_hook before return. So the information doesn't survive to > >> the wrapper. > >> > > > > I was thinking more that internally you already have that information > > you need to know to skip the zeroing - and so the wrapper can just pass > > __GFP_ZERO and post_alloc_hook() would do the right thing regardless > > > > Then on the way out, the new wrapper would take care of cacheline piece. > > > > However, i explored this a bit - and while it saves some churn on the > > interface, it adds two paths into the buddy - and that increase in > > surface might not be worth it. > > > > So I see the tradeoff here. The churn is probably worth it. > > In v2 I commented [1] > > " > For example, instead of changing all callers of post_alloc_hook() to > pass USER_ADDR_NONE, can we make post_alloc_hook() a simple wrapper > around a variant that consumes an address. > > So isn't there a way we can just keep the changes mostly to mm/page_alloc.c? > " > > That should avoid most of the churn outside of page_alloc, no? > > [1] https://lore.kernel.org/r/4bdc66f2-1469-4b91-9935-74c3d3ca0ed9@kernel.org > > -- > Cheers, > > David Yes I'm sorry I missed that one and didn't answer it. My bad. To answer the question, no, definitely not *most*. Here are some numbers: What we save: 11 one-line changes adding , USER_ADDR_NONE in callers that don't care about user_addr (compaction, filemap, khugepaged, migrate, page_frag_cache, shmem, slub, swap_state). Changes we have to add: 8 changes Rename 4 existing APIs adding _user: __alloc_pages, __folio_alloc, folio_alloc_mpol, __alloc_frozen_pages + add 4 wrapper macros/inlines in gfp.h that forward to the _user variants with USER_ADDR_NONE. Roughly 6-8 lines of boilerplate per API. What stays the same, but now has to call the new APIs: all internal plumbing (page_alloc.c, mempolicy.c, internal.h, hugetlb.c, the actual user-page callers in memory.c/huge_memory.c/highmem.h): 38 calls, of these 21 in page_alloc.c, 17 outside it. The changes would be less trivial to review, too. And I would not call the resulting very long names "elegant". More importantly, it makes it harder to review: instead of compiler checking we did not forget a parameter, it compiles fine, but we get a subtle slowdown or corruption on non x86. And I thought you agreed with this sentiment when you said "yea something that is harder to mess up would be nice": https://lore.kernel.org/all/20260414062524-mutt-send-email-mst@kernel.org/ >From where I stand, we would adding technical debt by piling up new wrapper APIs, for no benefit. But then, I'm not the maintainer here. And adding extra wrappers is easy for me. So, let me know. Thanks! -- MST