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.133.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 3F19B3E7BB7 for ; Mon, 8 Jun 2026 19:39:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780947580; cv=none; b=XPwUOUqcZuhOgBq3p1NzUnlgSsEaC0wxBDskrmP6oiDZClDD3jSh3aDI2z7iBY+b5B8N+IS+HlB948abM8TSwKgdcMlrPXtNirgZGUu5hB+EEXwzqZUHr+IRMdpCTs82ogGfsyAd4AuL6MOiHNCma8GIg7JqVDUR9/5wvpOJsYA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780947580; c=relaxed/simple; bh=skQdtmpohn7WRik717QBgGh9dXdmENEdeXodx+KKPB0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kgG4PyJ0KkIRoKdj/E9k/EIBoZn64nlhBGQ5Fs2ljuUr/YEHuwajogRbeV7WHcJ2aLlM+qwm0oVrU1t45lCaDOOyUYyUcM+h3xiAC274JJS/uZjbLWFQ2c7bJX/h+1n229DdFSht+FELk68j7KCuoDcYMv38u79s1Ciry0Jnd5g= 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=OLv1nHAv; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jL1A6sl8; arc=none smtp.client-ip=170.10.133.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="OLv1nHAv"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jL1A6sl8" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780947577; 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=ojAM3itDn3ZymS70Vu5Gl5MXdODLh0QLR6qk02zjekw=; b=OLv1nHAvrOopZNEABdZYfwwvJSefGILuYX1npk0OcuCNSP4DF61Y25jwMnPRlQxv5JxGSW rV7r0YDEkMY3QUyWgTHugGlK3YqMoKfyQWj8oXLTiSTKmc12uB564asOCqX4fwYM4icxkl WXgLSGUqeA1e/qQpG62oazrMW61aCDE= 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-108-XfXCiiG3O--F0QimaqDiAQ-1; Mon, 08 Jun 2026 15:39:30 -0400 X-MC-Unique: XfXCiiG3O--F0QimaqDiAQ-1 X-Mimecast-MFC-AGG-ID: XfXCiiG3O--F0QimaqDiAQ_1780947569 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-46010392f89so4309372f8f.2 for ; Mon, 08 Jun 2026 12:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780947569; x=1781552369; 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=ojAM3itDn3ZymS70Vu5Gl5MXdODLh0QLR6qk02zjekw=; b=jL1A6sl830f9N6kcouZahBC4d/Fg5W3DvMj1ylZYLApRp41YW19e4BOTakKBkdeQrm qPWUVZEHcNk+uLbwTAZIZTj8VS7UOLgHYS6rJYJGy6RO37SZgcn2hJrUyLvit3BBjnQM 2GgR+31h+P6/CWE4TTarqYhyc/D5b6brSU4RILU0Wc6c21OySASUfErK0i2CZaw0i3rC 9XGeOhyWBQdBchEuQ9mYLktj/D+iBnrOok7+w468s2u+RjuoSkFO2dxptcYIxwtrXp6H opscIXcKC+F3CnMlPfHIcN0erZqinFFZCoYB/KEH2onxeNYu2BcXj8jXsTBhm7p998Om 3A/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780947569; x=1781552369; 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=ojAM3itDn3ZymS70Vu5Gl5MXdODLh0QLR6qk02zjekw=; b=VEVSVe0qN28vCozeEzIJ9y0fC/AjP6CcwiCw0dd1NfZFj5dWj+q5kFlQqHvifT52KH Bo1cQg8gyYvRncEsAizOqE31QJZgm4D/03CcfMm1qER8Dyqeeh2FNQx0PMFmpepVT7Or vc8Z5c+Qw/WRIJjwVOvgVGoITORJ2ceOlRU8IEAOuT9Z41RUSFIuQBRIUcG9LBrewKjA 8XWaRcM0GHh2gY6bP9kdrUq6lnez+i7wWgyaHYGacPThjMEjXLQfNDYotxILHwGiAakI O9fqyEbyDxMlNn7s9Iwxl/GHUJoqQdWAATbRrKJXYWl8aa0gyJClHT/LII1e09f/CNU6 iAJA== X-Forwarded-Encrypted: i=1; AFNElJ+QYBHHq1X8w5OYPEKuNswEKwCH4LlcgRdCXgRbc7pLBS8nKyJ8BR71fGadkTrX9Y5DnT3ke7Oj6v3KNfk=@vger.kernel.org X-Gm-Message-State: AOJu0Yyzo+HpJGpJ3zmeImUn+3W+z0KDeyTFla00ktTipeLkI+K4wjAW nePcKtQcxT2+GstDRSkuvDeZK3wkvj+Ya3LfqBRLV0AVh7qTNBUhhlKXywLSFEbX3Y74Z9zp+PD Awiys0hANKEeHAZZoiQE25S94JTXxkvJ/n88eg5nH/b4UGxF9Zjy47UaE75+rN77RIA== X-Gm-Gg: Acq92OFq92dkbkTCWNmqFPV9oRxk/wZaUlwkTm4u2VSuxsNr0o2+8UAL4FoBaCd7zDI HgGWgOu/P1vyaR37VYNdSCCn9DCmQ2CdG6Byr6ufKmudpFh+wpWcRbB2wSVbd9BTWlUvp72pW+p Xo+nyFY+MPXYI3PEzhecOwscEbacsTt/RWceKEIZ/QafCK7i935C7fpQ202+og7JhQlSWbQ66MB QddOUZ2zWwhTGKGmBPTwRED37c6Y1OUnrnC9/A8d8BTVe8AqiK/8sNliSUkdJO2NcvCcyuJAEZo 8ub1bWgGkfyfQFmIsF9KPRSuuZU16yhlp9dWsmwXE6m9ZlcUuLWiMJ36HufKp3Z1jcBNxC2MvwG socIGWAQrKReL6nirgatG0dFTaSlfLONMI9R9HFCj5teHpN5eTUphyA== X-Received: by 2002:a5d:4b41:0:b0:45e:f3b2:122a with SMTP id ffacd0b85a97d-46030652fcemr21261551f8f.26.1780947569313; Mon, 08 Jun 2026 12:39:29 -0700 (PDT) X-Received: by 2002:a5d:4b41:0:b0:45e:f3b2:122a with SMTP id ffacd0b85a97d-46030652fcemr21261482f8f.26.1780947568821; Mon, 08 Jun 2026 12:39:28 -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-4601f2dcde3sm56739949f8f.1.2026.06.08.12.39.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 12:39:28 -0700 (PDT) Date: Mon, 8 Jun 2026 15:39:22 -0400 From: "Michael S. Tsirkin" To: Lorenzo Stoakes Cc: Gregory Price , "Vlastimil Babka (SUSE)" , 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" , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , 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 00/37] mm/virtio: skip redundant zeroing of host-zeroed pages Message-ID: <20260608153600-mutt-send-email-mst@kernel.org> References: <8d5d2fa3-a60c-4d04-b3bf-7a8fe89cb1a0@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 06:50:46PM +0100, Lorenzo Stoakes wrote: > On Mon, Jun 08, 2026 at 11:45:18AM -0400, Gregory Price wrote: > > On Mon, Jun 08, 2026 at 01:13:42PM +0200, Vlastimil Babka (SUSE) wrote: > > > On 6/8/26 13:02, Vlastimil Babka (SUSE) wrote: > > > > On 6/8/26 10:33, Michael S. Tsirkin wrote: > > > >> Further, on architectures with aliasing caches, upstream with init_on_alloc > > > > > > > > It seems those are niche architectures so we can ignore that part for perf > > > > purposes; the other reason why user_alloc_needs_zeroing() would be true is > > > > booting with init_on_alloc. > > > > > > OK I misread how user_alloc_needs_zeroing() works wrt init_on_alloc, as it's > > > negated. But you're changing that anyway to skip that user zeroing, right? > > > > > > " > > > This series eliminates that double-zeroing by moving the zeroing > > > into the post_alloc_hook + propagating the "host > > > already zeroed this page" information through the buddy allocator. > > > " > > > > > > So relying on "everything in buddy is zeroed" would still work I'd think. > > > > > > > This regresses for anything that previously didn't zero on free or > > alloc, which is most kernel allocations. > > > > I think the scope of this set has increased too much based on early > > feedback to fix the userland-initiated allocations piece along with the > > balloon/reporting/double-zero piece. That's making all of this > > difficult to continue following. > > Yeah I feel this is 3, 4 or 5 series put together, and there's a lot to > discuss in each :) so it's pretty difficult to work with them all put > together. > > These need to be deferred/separated. I can do that, it's just that the real performance benefits only come with the last patches in the series. If I send series that merely moves zeroing around, with a bunch of threading of addresses and stuff to achieve that, 0 perf gain and slight degradation in corner cases like memcg failures, you feel it will be well received? You guys really want to do that, independently of the rest? Just making sure, I'm not the maintainer here. > > > > ~Gregory > > Thanks, Lorenzo