From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (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 E1E501D5CE0 for ; Tue, 21 Apr 2026 02:38:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776739104; cv=none; b=aU3d0m7smtqCIk8XDihiCZmNgo95tdjjKxsKNphuyO2fMkQevHlNqqLMHovpwZwMU3DCi7Hrj6FVpGYpB6nDSqdZiGwq+QZpBRsfpzDAaOqKfXWa6GGizGh7gaatTzyRMAnMMtVMNs8FaJ+IUS3+zhoGxQtZT4QuC/2IkJicauw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776739104; c=relaxed/simple; bh=34cMY+cN1mpIU3dBjwx4ZxTWTie7LIYAGZMXqTKBXmg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UebTzWA0cw4wfnGY0ZPnc42sWvf1KIc1i71c08ccA0NlcyudTqvCHdnwUE4jy/VD2le8PeMhUXCCRC6LjECBqovdtHUS4+NrFCSFZESzzyfxsrf5nIRD6Ml8q4eLVjhDXkElRbsC05sia4NVimMRQDgabaHbNi/s5ZIydIVZTHI= 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=uW6rYq3r; arc=none smtp.client-ip=209.85.222.171 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="uW6rYq3r" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8e0a768331cso485749485a.0 for ; Mon, 20 Apr 2026 19:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1776739102; x=1777343902; 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=DFzhmNd1adFIkSfM46o3U59L62f2VQ0RrNdAOEaBXO0=; b=uW6rYq3rtp4CehNCi4oZeWRkBLsQMSwa+/Lvz1ECo0/EsD6t60QhyZGEkOLuYqFAAW zpDf+YZnBHdWgZGzEFXvlZ38iCDRnrjrdCnAzBBTjuKxtIL79IwF/FH34b0VFX3IeFWo n5+scDBvsH9h6cMjVcCLl5I/HOC2jSfwAQBeAZ2txQmF0HMPCn8Ys0CHuLTKoc3XWrLr lCMO80JrohQr6gge66PG+7OivbWTflAJKnJlp7AFMJqynCDVBmqe4qCJQQSUlueQqcO/ MaIVI9VFZhFNaPnDKB6iEqykJZ5rMhhOEKYdv8T0la1Qgx6fDW9j6Z7rtwAZ1AluCFj9 iQKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776739102; x=1777343902; 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=DFzhmNd1adFIkSfM46o3U59L62f2VQ0RrNdAOEaBXO0=; b=YfndddcHi6P6X4GIPa7CvvjpxqJ+K4JZ4YxnH1HzzIwphXREP3klZIxEva6snEW1SH jvoClZG5Hu5nQfz26N8GUasx7JvEePtw75byzXyfX8DPMIKVcXooUB0N0Rjjx+KPdc1S pGRglHPIyHS7+847VsFG6gUghACwbXVo0bqeXpibsV7VXZX8yXl2YXFccXhY/XKbcG5h YM7YS/r7Cx17dLvvqh8vdmvgnXRsQQzEAsReCbOj8hAfeWGjerGerRSkELvGewhSAxLp z6Imn3nsOZUX+hwkxfCdEHjSA12E4WzDF67BEY0bvW5LPZI4Hsj2HVgcRTFycSFAD1zy aJEw== X-Forwarded-Encrypted: i=1; AFNElJ874Pe2t4qBTVrBOcipK8LFodIOJaFYvq3lKjIdN1+H/zK2gFgqIJFl6tDpnIOb9kAw0NMYp5Zcu25LVMc=@vger.kernel.org X-Gm-Message-State: AOJu0YwgifSCI9FOEgjx7CMpYTDWQ8IS1FmOguh8TtgEACQXXL9gjfRK hKwxHg4zGevCkhyMOLytbbZPuSUuUaSStsbrrgISI79B2hBfS7/U7K6nmiqNU21uSg4= X-Gm-Gg: AeBDietwlgYYn3urQ0301J8BG6ghcPgpi3xlYMAos7mfeo1JTUl5noq2PZHBf+Mz+VX GsvD9MZUS2ViiTL2wlXwZ0T40EhkI+sl+//NP7NZtENrLCfj9d/0bf4mUS93y3Ut3YviO0gxsAx dGDVXbwEOUcn7vln4BGPOiayD6b3P6dyMwPPoVklHcdeuoTpz2M2WwO5Qz8z36ZAY+67q4jp/Jn O+atuTbVw20m+oB4Yv/xOs78lMVHmpDsf6PfqVZ7NkQsxXqswzkpZS921GB0iFL/8MH2SXMN8zA qHMcoLFb/gvHgGpNb+E8bhEpdzp09HueZMwjYvwtJ0uMwWXi16nAeMvME1/Ol7iFXNmiDC2hqcy 0rsFxXWOMnW+5DOFsu1K1nFO0X8tf54NmKfE5UtykOUvPvJ8PI2koOE56qbEzu6Nxk1MFAy//pc OzXPLLJ9/gD7RXuZMxFCvyNO6xYxZ+i/um4UTOCVG8Yj/lerKtxeqTqC/7SzksclldHkok7d9pL t47P4Qndc4pPuIW2lf/l3XyXPNo3O/ahw== X-Received: by 2002:a05:620a:19a6:b0:8cd:88ea:fd21 with SMTP id af79cd13be357-8e78c5c1fe0mr2065685285a.21.1776739101852; Mon, 20 Apr 2026 19:38:21 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-108-51-163-112.washdc.fios.verizon.net. [108.51.163.112]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8e7d5fe90afsm1079220085a.3.2026.04.20.19.38.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 19:38:21 -0700 (PDT) Date: Mon, 20 Apr 2026 22:38:19 -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 Subject: Re: [PATCH RFC v2 00/18] mm/virtio: skip redundant zeroing of host-zeroed reported pages Message-ID: References: <20260420192037-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: <20260420192037-mutt-send-email-mst@kernel.org> On Mon, Apr 20, 2026 at 07:33:38PM -0400, Michael S. Tsirkin wrote: > On Mon, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote: > > On 4/20/26 14:51, Michael S. Tsirkin wrote: > > > > A lot of churn, and my concern is, if we miss even one > > > place, silent, subtle data corruption will result and only > > > on some arches (x86 will be fine). > > > > Which would *already* be the case of you use folio_alloc(GFP_ZERO) > > instead of magical vma_alloc_folio() + folio_zero_user(). > > > > I don't really see how vma_alloc_folio_hints() -- that also consumes the > > address -- is any better in that regard? > > By itself, it is not. But the issue is propagating the address from > there all over mm. If we miss even one place - we get a subtle cache > corruption on non x86. > Why does it need to propogate? Can we leave folio_zero_user() callers the same, but add a PG_zeroed check in folio_zero_user() that skips the zeroing (but not the cache flush) and clear the PG_zeroed bit? Is this feasible? You don't eliminate the folio_zero_user(), but maybe we shouldn't? (a bit naive here - i haven't checked the PG_zeroed lifetime, i did see it overloads PG_private - so this might not be feasible) > > I also note that we need a flag for free in order to implement > balloon deflate as you asked. Here, I reused the hints. > I'd sooner just implement this as ___put_folio(folio, gfp_t) __put_folio(folio) { ___put_folio(folio, NULL); } And change the free path to take overloaded gfp flags. Some of the existing ones might even be useful as-is. It's essentially the same thing, but prevents a bunch of churn and saves us a new concept. optional gfp flags on free seem like genuinely useful interface for certain callers (definitely not all). ~Gregory