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 3811D37998B for ; Mon, 8 Jun 2026 21:04:57 +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=1780952699; cv=none; b=AGFZvq2YFmTKLKtwzVKzMH8EGaWHQoBPboh52dW0EkhwqhsxsvdrL4zJHSWd/+QWSfgGOBu5AbLXyA334pcr23U4J4uhi0MQgy5WmB6FPSnicnBZHzxaLwlusQufnVI1CBb2XkKs7mLXjxWjlrcdutKEVxJVmzPuWJSiqRfzIqY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780952699; c=relaxed/simple; bh=OgF9k+IiDMtBnvBE0GxYSZsQiXwofytTaJX9Y9hKkt4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kK+aA7m7GmbsC06ktMcYYUPsnXpa+mG53AfLxEfwyBPd4gn6hWBAPq0t+NCSb4PySjg0yXg4Q6Dvg5BgWQnPFof8knwIqThfmsv2PeK/V7BdGCB7NYMRdg6sLdaqrxY77447u4szJVLiCTs3epSJH63TSnKN1MpVhBIY3k5sC7A= 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=i20g3p/I; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=D+wVivl4; 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="i20g3p/I"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="D+wVivl4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780952697; 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=CG7TX63y8ii7nF3o7st9M+h9AET+tnVYkN3+ZIy7R/k=; b=i20g3p/IoZTtiSpbfL7COtgsDcg3fw7/XCAy2eeGd9TkzRcurzwksnNj1ui9rVKFMf+llJ cprw9f4uYwdNLyIXH3EYX6GkwkA7d6GQvWNaV9pDH7mYgCjgELuBp1XXNW2F6xT9jkKzO+ ot4dWX+M9eXvd2IpLzhBCcElzUHC4sE= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-177-o7fzeD2NOau53sT35nYnSQ-1; Mon, 08 Jun 2026 17:04:56 -0400 X-MC-Unique: o7fzeD2NOau53sT35nYnSQ-1 X-Mimecast-MFC-AGG-ID: o7fzeD2NOau53sT35nYnSQ_1780952695 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-46011aa5000so2034534f8f.3 for ; Mon, 08 Jun 2026 14:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780952695; x=1781557495; 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=CG7TX63y8ii7nF3o7st9M+h9AET+tnVYkN3+ZIy7R/k=; b=D+wVivl4vlpiojCJjHMDIie7IavIK3mOmz5XzzyY4IUEAwo50QM+wgnBuMhpvWSjET RbnamNe32QVRD/3HspMY68G7z391LIfWGNF1DTRKzSfSpm+Z3fUeE/RGF2E8/PZBWEon iUZBqfRKks+1RzrpThoY+GYeZi/+2mXIGAE/UrEkJuLzEcJEJU1+H3v4DM36uGIItQ7x /DZg4k1lyQ+ZurD8JHgP+zKuEQL8r1mdyvC7A/5ha4xbLe1aMIgoZT7JPwTl0/qcGsQG 4Lug6nq3qB6ELoUB4ZpfWnW0xvD/kJu2wrFvvsf8UlKhASwgGVBgua/RURtHgmErNK2g 8r8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780952695; x=1781557495; 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=CG7TX63y8ii7nF3o7st9M+h9AET+tnVYkN3+ZIy7R/k=; b=qcfNZkPBAwuCOxz1Svgu+/ZXXJbzs1oY6pc/PUtvt0RtYh3lo+l9qPEWappWRBwSCk YvC5h1ItTLzgUHln6PkAIdBZBNN9CQdgy5vHjkfi+HHfCqgQO19eCL0U0L1I7tmtO//Y mElJ6QGlLnDyZJyw4Ru9gHyvlT0PLIQ9DZa+cA/Hh0ik7+r3egfocQZMdrcDQRXf0XHx 0hBLRcVpjoRP1xg9cSQALYpoh6UeHEp4DkJ4xcKyxjXx9g2W5N4Zw+8czzBXUuRBh0fz kmTHe2H35Gnd3+XOD2L8GiTvKFC/9tobSLjgWZ59UWFp+dyIxV7usxUdzntfBPzl7ZZ7 vVRQ== X-Forwarded-Encrypted: i=1; AFNElJ/qxzXv5wk/EdBIH/mQ3FoWb+slVjuibtxst9577Jb3M2IrerAAVyL/ZlpAnLjE9CtwW8FKSamXXDv9sj8=@vger.kernel.org X-Gm-Message-State: AOJu0YznVyi0JE4xSXR0mleO6WtmFHm+ORhlcfb3vrVJTYJJroy8qBIn DXuPNxawoEUNm6vRT0z8ARohgxmk5sQTMcoweTLIOHbcOHwJzX4nF6v+J/SoNrWpnitzk0AU859 OkNrAKGP+yVUdAZENELCbo5ITeaiH+jRmBvW5VxZ9aTNwcx7ZH+H0ZhO27iIWcz8rTw== X-Gm-Gg: Acq92OFz76dsu8HhZuuQO5QjWaD1S82tVyULNcn/qymG/D3rChGYrF+xcHCY1fdan8p eVagLFNaHnqTky4e9Jw4U/hVbh675UGGER1ULJkzXMuvqkqVY9Gd95sQH3DyF7bG0FaC5OEb/f7 vOBFWwbuP3smP4JOJ3p5PE91kKMCek/xgeOqsCJzoRuopkD4eW4RPqurp1K4W086Vs3qp8f8knx YkR+kgJkA6IgQXzNek2+ahm38zcJgobuNCeEW+m6kdnMxkSYxsb2Ktsl6nJaf5fdrj37hVPg5O2 IDLMmefLtBmWEnZCVrhug3yJsI43bVoB3VQJb9ceS6jcsX01XRV7/T8mRxwWMUYC0xsu0k8zoxx A3YOcYtHs83fOfSLCi3ShhjuY0C0I4OtXMHtuQ+AAP69o6V3yIoL/nQ== X-Received: by 2002:a05:6000:46cd:b0:460:1492:4f0d with SMTP id ffacd0b85a97d-4603063c591mr17367268f8f.34.1780952694648; Mon, 08 Jun 2026 14:04:54 -0700 (PDT) X-Received: by 2002:a05:6000:46cd:b0:460:1492:4f0d with SMTP id ffacd0b85a97d-4603063c591mr17367215f8f.34.1780952694170; Mon, 08 Jun 2026 14:04:54 -0700 (PDT) Received: from redhat.com (IGLD-80-230-85-71.inter.net.il. [80.230.85.71]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f351ac0sm100416244f8f.27.2026.06.08.14.04.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 14:04:53 -0700 (PDT) Date: Mon, 8 Jun 2026 17:04:48 -0400 From: "Michael S. Tsirkin" To: Zi Yan Cc: Gregory Price , Matthew Wilcox , Lorenzo Stoakes , linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , 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: <20260608170348-mutt-send-email-mst@kernel.org> References: <50d410b47fe3f45327783e05bd306d5eaab75e65.1780906288.git.mst@redhat.com> <20260608163257-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 Mon, Jun 08, 2026 at 04:40:15PM -0400, Zi Yan wrote: > On 8 Jun 2026, at 16:33, Michael S. Tsirkin wrote: > > > On Mon, Jun 08, 2026 at 04:21:08PM -0400, Zi Yan wrote: > >> On 8 Jun 2026, at 15:59, Gregory Price wrote: > >> > >>> On Mon, Jun 08, 2026 at 02:04:28PM +0100, Matthew Wilcox wrote: > >>>> On Mon, Jun 08, 2026 at 12:06:35PM +0100, Lorenzo Stoakes wrote: > >>>>> But instead of overloading user_addr to indicate all kinds of things, instead > >>>>> make life easier by actually breaking things out. > >>>>> > >>>>> Like: > >>>>> > >>>>> enum alloc_context_type { > >>>>> KERNEL_ALLOCATION, > >>>>> USER_MAPPED_ALLOCATION, > >>>>> USER_UNMAPPED_ALLOCATION, // Maybe? Do we ever? > >>>>> /* Perhaps some other states we want to encode? */ > >>>>> }; > >>>>> > >>>>> struct alloc_context { > >>>>> ... > >>>>> > >>>>> enum alloc_context_type type; > >>>>> unsigned long user_addr; // Only set if type == USER_ALLOCATION > >>>>> > >>>>> // Maybe something suggesting context or whether we init before in some > >>>>> // cases? > >>>>> }; > >>>> > >>>> Ugh, please, no. As I suggested last time I commented on this > >>>> trainwreck of a series, lift the zeroing functionality from > >>>> alloc_frozen_pages() into its callers. > >>> > >>> This sort of just implies writing the "alloc_frozen_zeroed_pages()" > >>> wrapper that does the zeroing at the end before return, and then killing > >>> the post hook nonsense associated with it in the first place. > >> > >> This means it is going to be a multi-step optimization. This is probably > >> step 1. > >> > >>> > >>> None of this resolves the user address annoyance which is needed on some > >>> archs for cache flushing. Whether anyone agrees that the page allocator > >>> should be responsible for this particular operation - open debate. > >> > >> This is probably step 2. But does the virtio use case apply to these > >> archs? Does the performance matter for them? If not, maybe this part can > >> be left as a TODO. > >> > >> > >> Best Regards, > >> Yan, Zi > > > > I doubt it. But I don't get what's proposed, the code that we > > have to modify is arch independent? > > Change user_alloc_needs_zeroing() to only check address aliasing even > if that can cause double zeroing for virtio. > > Best Regards, > Yan, Zi Ah. I started with exactly that in v1/v2. It's a simple approach. But mm maintainers said no, user_alloc_needs_zeroing is a hack and I must not add to it. -- MST