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 B46863CF049 for ; Mon, 20 Apr 2026 23:33:45 +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=1776728028; cv=none; b=j7B38drKB3FNQHTR5NgPEO1rtaKxJjVlqR9OSV2K0X2DFYOX41pyATc+D184gxLXl/75/IxbQX87WhiweWyZfYbnEmCf7UgV4kRnTivH0oojfOz8lkXqK8GknEhtaHG3L2NRQmbtpP3+4SuxJCJTz7UGRf4XdZFASFTe1FmpW88= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776728028; c=relaxed/simple; bh=yR2/wB5ZyxKUGr0AdiVEcbgQkku+GxQ+Y+qdUpCrdgk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TDK/bsSKFyAhZDe5fVwLmkfpRbIXJICtbbIuWiu6N5Fcezn3Owb3vxrnSNqUxMycaOg/Y5jblnX3rzTJemez1Sv/06tZHQVtqN+qz7f9aqLKx3kOnpDiKnJ6jqdP8vXVc9dd7jIGU2QLZ3ID39ameeLRCEwCqy5AJVT7boOVawo= 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=XqNd5nZw; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=r621r1Yh; 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="XqNd5nZw"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="r621r1Yh" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776728024; 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=Crl5IidACm0/Y50tYB/yaiHCDukvD9pxpf1tedSp32Q=; b=XqNd5nZw6uHDMoZFQVhicT6SAlbrCcS38jI4C5iqMj/oE0xoX66QaNSO2CyarHjDkI66vG /tYviE+Zxp27+J3bIc4oMAieV1exBZ+e49qHHotXxbqAFmglM69erGdoc2mSx8+YRDQN1Y HuTYFl+BIXV889OOc0wsIq5km7opkNk= 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-526-O68Rf3AaMuiV7LOh1pwvzQ-1; Mon, 20 Apr 2026 19:33:43 -0400 X-MC-Unique: O68Rf3AaMuiV7LOh1pwvzQ-1 X-Mimecast-MFC-AGG-ID: O68Rf3AaMuiV7LOh1pwvzQ_1776728022 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-43d744128b9so2989323f8f.0 for ; Mon, 20 Apr 2026 16:33:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776728022; x=1777332822; 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=Crl5IidACm0/Y50tYB/yaiHCDukvD9pxpf1tedSp32Q=; b=r621r1YhGzdAvWps5/cD7yq4UayDexzi7pq7MXALHvCVzkDqR0jVl/hqUmCSQwRpDW oFEaCf1t0BB8maUp4SAnqx98lzGjOYz7hpANQkwxYsVJKlLI8zc/EWJHmY7AtZ8dxDtr 0tLxEQxsLtzIssl0LZBJXeKZy8m05XaWTqa83VI+V7/S2qRd/PUsVgFLXbiJabrs2cqz bJu0+PtibiGfM3NdL/G0Ie3O4OgEUHlZ+jefM3nSbdSFyVmKYN+m0yrDI8V99ZMNYnC+ eUS5XVshcy+qHH5zeloGBLX3o2je+xMSQeoZqFVjNNR8Q5Nnq48mMRy2St3YFVA+NDa0 p5dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776728022; x=1777332822; 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=Crl5IidACm0/Y50tYB/yaiHCDukvD9pxpf1tedSp32Q=; b=Tuh1co/It9HCwWD8dfWYrUYTxQZWv2EwElu4CoZ8Z9du+SVyoDqY03H97OLYeqxQL6 eU27cIDr0vcHUjWTKBIkPFiNnYIDwai1oLpxwVZ3biUQ+aq124608WOmcSj4fUk2Ia8c 3331OTJxD2abF4G/NmnmgWTv/+28CpfhpbwF2nHHnp9j8A4yFpuUCvu7VZLiT6N/gfSL q9s/BoVpjaQLfjRWzKdRD4WQx6QLiHS6PAdUwH68U7oYEmqT3TheemEpj4FQF7TjdTJG Ap+CHEFRluowfFhEmewsqrktCM0/Ftx6EDf+mpjnAG/cwXtMTz3Ig8O82Wp2tzj6wIwk MylQ== X-Gm-Message-State: AOJu0YyhLWBeFNifNpV85dCyzaAmJMoAuPoqZnF60pADyMaoQZUtJpTO VPLbAHnYULOUQxurbc2fTrghf6Y05XIIT4FqeDBGuSnhhuC9chgNffv99YVetTE1uPPxoWwvvk2 nJBN90V5FJwLLMEpKS/5fprCVial6zRNT0bPqMJx+K499jKBVzWvX8PruWpYyWGwuVg== X-Gm-Gg: AeBDieufmUt7m+hHhA9mOrOvqTeNJqwmhqUfPUE0BrrdW2eiDWUTuLexuTzueb8ts3z D4vcabxUkjX0rdmLC2D5mFIj2q7BIsaFdZ3tLQgcXUgDKfwLRpo+Fn+88uJxODcKRU6K/MD0GV6 dnvxEHP2H61GmdU9bkU8i8w7++Au94ADYJUN4uWHsifnq/25NWrDQj5jSoobi6KtHtaC5dsXSM5 39gS9eWUsYem1m/A4v7NInH3o0SkbXlFjSCzopWl/MUoC3jKTVVvkh1mGZDeaP2N+eiFygV2Jd6 bAUgyIOf2jq3Ehw5vtP/SqfC4EFDBbxuaSnD8XX5b/5z+Umq800SCoMRLA6RT/LCwJ1ahN6YE5t x4j/Q5dGYRtdgqWhMbwYojOTMmxvGMnidHnfcY/rVbej0ZtbxgDU+LQ== X-Received: by 2002:a05:600c:5294:b0:486:fa35:aef2 with SMTP id 5b1f17b1804b1-488fb73d53bmr206894945e9.4.1776728022108; Mon, 20 Apr 2026 16:33:42 -0700 (PDT) X-Received: by 2002:a05:600c:5294:b0:486:fa35:aef2 with SMTP id 5b1f17b1804b1-488fb73d53bmr206894725e9.4.1776728021660; Mon, 20 Apr 2026 16:33:41 -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-488ffc558f2sm191637225e9.1.2026.04.20.16.33.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Apr 2026 16:33:41 -0700 (PDT) Date: Mon, 20 Apr 2026 19:33:38 -0400 From: "Michael S. Tsirkin" To: "David Hildenbrand (Arm)" Cc: 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: <20260420192037-mutt-send-email-mst@kernel.org> References: 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, Apr 20, 2026 at 08:20:57PM +0200, David Hildenbrand (Arm) wrote: > On 4/20/26 14:51, Michael S. Tsirkin wrote: > > > > Hi! > > > > > v2 - this is an attempt to address David Hildenbrand's comments: > > overloading GFP and using page->private, support for > > balloon deflate. > > > > I hope this one is acceptable, API wise. > > > > I also went ahead and implemented an alternative approach > > that David suggested: > > using GFP_ZERO to zero userspace pages. > > The issue is simple: on some architectures, one has to know the > > userspace fault address in order to flush the cache. > > > > So, I had to propagate the fault address everywhere. > > As I said, that might not be necessary. vma_alloc_folio() is the > interface we mostly care about in that regard. > I'm not sure I follow what "might not be necessary". We need a fault address so zeroing can be effective wrt cache. Since you asked that it's done deep in post alloc hook, the address has to propagate all over mm. > > 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. hints are exactly that - if we forget to set them, all that happens is that we do an extra zeroing. That is all. > When we just do the right thing with vma_alloc_folio(GFP_ZERO), at least > vma_alloc_folio() users will not accidentally do the wrong thing by > forgetting to use folio_zero_user(). Well, it's simply that 1. if you plain forget folio_zero_user you get non zero on all arches 2. we *already* have folio_zero_user in place > > > > Still, you can view that approach here: > > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git gfp_zero > > > > David, if you still feel I should switch to that approach, > > let me know. Personally, I'd rather keep that as a separate > > project from this optimization. > I'd prefer if we extend vma_alloc_folio() to just handle GFP_ZERO for us. Pls take a look at that tree then. What do you think of that approach? Better? If you want it in form of patches, I can post them in private or on list. Let me know, I don't have a problem with that approach - I tested it and the performance is the same. But the issue is that there's lot of paths that have to propagate the fault address. It took me a while to even find them all (assuming I found them all). I also note that we need a flag for free in order to implement balloon deflate as you asked. Here, I reused the hints. > But let's hear other opinions first. > > -- > Cheers, > > David