From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 CC7F52C11D7 for ; Thu, 23 Apr 2026 13:42:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776951763; cv=none; b=LhrVxLeH3VxOfPu801A4u3v3yCrNJ4odPRr/3oNSQ9C9p7ywmyv+2f0+eoYojnKo/C1tgGbjZR9dseKzDU8JqZ2mjxG1Zy1DzB6x4LlXnX4zrq+9Z8H/A0QaK9wCJMw/ba+GZm2/9QEyMfRXxyHiu4fVhz3ugmZByO0V7lLim6A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776951763; c=relaxed/simple; bh=6KH/ThtXPOGPGdSUrvGlCAHA82rT3JIzigfXoEPge1k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dgFGAyeLsZsG+9jp5lZzmh1W6qepHtcaB11+QGuBjXoVhTGvGr+NcKygdU6yISbtW99jTVCPsa42AUy5/D03yqj0XIATJ0DQVZzPoP9AgKYS1+dTiB8IDmGHRhKQQwuRt4aFCV+IBoYKkt+3lK+vOkP+sWeK0c6MxrvZHg0ow8A= 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=NZRMmhEO; arc=none smtp.client-ip=209.85.222.178 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="NZRMmhEO" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-8dbbc6c16b2so832204085a.0 for ; Thu, 23 Apr 2026 06:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1776951761; x=1777556561; 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=0SbK7jHzK0BibVPY47BIZzJ6hwGVNdmSnj/6qVo16wg=; b=NZRMmhEOSc3sHpC2xhzJFB2KMnJ9WgWSDdxUSaw7HRsrFU74A+K77AWiywfDt0/yw4 3y76PXU5ujqubgdRc7EvTsHis4Mj6izR4fXihedsmMwbB3GonzLVvPqxJYmpZ/2tKALm ZbxWvLF6OGiiCFoR/G78Un5pHWQiYOdaA9GmlR6Xj2hdonH7mnSedccBvH/ZyesvijSS TW3juLgzwz11TUu2+SpduV0GnVeYpUIbCJJfRskq3JQjXlK5dz6hkGZfJWESH5KPbDb8 27dCzpG3JOlsGGzjdZL8jXCpwZ0Q9jZzWrhVQf3suL1lpRZrKzpNJHQqviJ7qkRuTsMy jV8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776951761; x=1777556561; 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=0SbK7jHzK0BibVPY47BIZzJ6hwGVNdmSnj/6qVo16wg=; b=lWfUHLN/oMNqRoLwg1sIM5XBfc9xyfOgBycWz/zBhLmaHxCDeoG7tj76wnnk1LorVj eHWpeHbvymyKN4CUzlaDNHk85HOvt/j6/YXcoXrYd7s1AbOkKTxUTitm6qXZcjwdtLF4 WFIyez6w2vO8ehuuv1LRp21sViJffE9Hky1BzplmV531p/mjsFQ0fkJdOIK+N/I030R2 AG3hjLqJhwRiUjuGCT+HDdSJPadTWKEvAn0PcCMtAvPfGcnEV76TgNDcNH1Ec4dMq68U Xom+B94FNXV+xhykSnL2ytig75QPRs178sjccdDdhIJmHM7fOxtVUmwN3MrVtYZhCfEs bSqQ== X-Forwarded-Encrypted: i=1; AFNElJ8ulGA1bXIsRSHoa5dhuPYbVMiNlE3njlehOQdPo/kmamy1pgBAhQVwySGnx/T42MyKDe88pXVTyk+TWYg=@vger.kernel.org X-Gm-Message-State: AOJu0YwoArmwyMx21hGmH2kKvbh+3GZJhj5wK7gzZvXOk/KK5mGR93HQ rrqfEaxJ0laHVd0U7vvhZ52ncK7E2EiECsM/Uj9iqlPdH2pJe6x5Kv5MFNLvxXHjJL4ByW4NiCa nrg44 X-Gm-Gg: AeBDievCoPrRjQTx61ePDOBl38RR/RF7K+i2FuaEqPls0xcI0GL0uoro0duEfzuZ5Xe zm47m904/iS8fAbSqaSnSNBQXQ8hoEAfK9sT62NV3+A5JQZ/y6v8dPWIU45BpSf55GHpbPRECeI kppzSOL/4T+QMBrw+g1KJAAj6N5TR490ZLSuSzguhjfGCgGVTavPrsMf2GbFm/3LGe6cutzcHpN RZUSnoj+t1wkRditwWsLJPPKgEzuvA8oGiTQHhTbWKcqPn33iE23YoA7iqV5gAykQJhXo+qIwbw crd2UbX0S5+0WuctwGzcH4zKsiC2letBSzQS8WuryfwGrmpexTZVq6RbRUKTjsxh6RkP76PXMMd lGXhDvqJ1WESa6uW+d5fxJvlJE0sONLEPXvodR56ZsruCK1FI+GOTa/UN7xaFkL4tRfd12IN/vR X2fhaKFcOZRIhV1h3Hw7jxcwhuF/Ti5/j/J4VVg5znI9XmCGUSalRXBHac3FBfW7kzphrbLLVR5 Pg4TrVhSC5aon6sBBeH X-Received: by 2002:a05:620a:414b:b0:8d9:26ca:7e3 with SMTP id af79cd13be357-8e78d0a865emr3247854085a.41.1776951760527; Thu, 23 Apr 2026 06:42:40 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-71-246-228-50.washdc.fios.verizon.net. [71.246.228.50]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8b02ac81a9dsm157783036d6.21.2026.04.23.06.42.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 06:42:40 -0700 (PDT) Date: Thu, 23 Apr 2026 09:42:37 -0400 From: Gregory Price To: "Michael S. Tsirkin" Cc: "David Hildenbrand (Arm)" , 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: References: <9dd9deabd42801f3c344326991d1431c3d8db39d.1776808210.git.mst@redhat.com> <20260422171315-mutt-send-email-mst@kernel.org> <20260423074433-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: <20260423074433-mutt-send-email-mst@kernel.org> On Thu, Apr 23, 2026 at 07:57:01AM -0400, Michael S. Tsirkin wrote: > On Thu, Apr 23, 2026 at 11:46:56AM +0200, David Hildenbrand (Arm) wrote: > > On 4/23/26 06:31, Gregory Price wrote: > > 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. > This is essentially what i was proposing. The result would be more external surface to the buddy (at least 2 maybe more functions, plus all the _noprof stuff and a bunch of other things). And then all the callers have to be updated anywhere, and not make it any harder to mess up. You either have old_interface(..., user_addr); /* Churn everything using the old interface */ or __internal(..., user_addr) { } old_interface(...) { __internal(..., NO_USER_ADDR); } new_interface(..., user_addr) { __internal(..., user_addr); } /* * Update some callsites to use new_interface() * mostly a bunch of _mpol() functions but some others */ but someone could still just as easily do old_interface(); /* don't fall folio_zero_user() - Bug! */ So it's not like this makes things any harder to mess up. There is no elegant fix here if we want to do this all inside the buddy. If the performance increase weren't so blatantly dramatic we could also consider just not doing this at all. There's maybe an alternative here in considering a change to the way the buddy manages zeroed pages - but there's no guarantees we find a pattern there either. ~Gregory