From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0E731C4345F for ; Thu, 11 Apr 2024 21:28:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 996876B0089; Thu, 11 Apr 2024 17:28:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 946026B008A; Thu, 11 Apr 2024 17:28:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 835366B008C; Thu, 11 Apr 2024 17:28:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 649996B0089 for ; Thu, 11 Apr 2024 17:28:33 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 0513A160D13 for ; Thu, 11 Apr 2024 21:28:32 +0000 (UTC) X-FDA: 81998540106.04.63ACBC4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 7DE9240014 for ; Thu, 11 Apr 2024 21:28:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=1rFSV6Wn; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712870910; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=CGBchDf72MHLYpj8TeQDEmQPqAQVUoX+ZpfflrBmX3M=; b=Rl+OA9L+m1rTHo+ywBLMoQd5YKNImMfYJOhutUun0kYFgvPxxFtx93h5x4HSujd9X9V648 /4ZenP9u5mKplNkp5TSs9qvDl5O+u/bhycUzGx5+NstrAZZ4J6tPe8sy/jvcCKCKUtwD1Z 7+1B0Menmc/MHKomTPOnAXC6ERpYFSw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=1rFSV6Wn; spf=pass (imf12.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712870910; a=rsa-sha256; cv=none; b=Z0RWARwHC87q/Kw00MkoB0OKc9kslNNMHykwSY0xZp2S2I337Ghf5yJL/tZolBnd7F4yM3 ZZfbSap44zwGvMtQ7mJh8EBa6JUnNmBi1IQQwstVNgvtMcL8HQilexHkz78oeJRMU1diG1 FBiheyJoIWq9TOa5f0wzixf8OFYtNak= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 69D0562139; Thu, 11 Apr 2024 21:28:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DDE9C072AA; Thu, 11 Apr 2024 21:28:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1712870909; bh=qYZJAos8Y1VlhyFh0wodG8r9EP6fTB4gaPBhuU18hO8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=1rFSV6WnuiT57XyEfZi728PpeWo2haLruBtoEN/Awm7LEedlT6WNJf8F+xyZCGAbv A/fAldqTr7ZyeA4IjWWh5av3FodBpvp0cpkMq0+hvyjt0yt+ElWoSI0swMmZrBNU6n olojFA0RW078omUyeBn/qiSahZ9Hne+LuXx1HR/I= Date: Thu, 11 Apr 2024 14:28:27 -0700 From: Andrew Morton To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christian Borntraeger , Janosch Frank , Claudio Imbrenda , Heiko Carstens , Vasily Gorbik , Peter Xu , Alexander Gordeev , Sven Schnelle , Gerald Schaefer , Andrea Arcangeli , kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: Re: [PATCH v3 0/2] s390/mm: shared zeropage + KVM fixes Message-Id: <20240411142827.d5c3bc401c6536bb1315049a@linux-foundation.org> In-Reply-To: <20240411161441.910170-1-david@redhat.com> References: <20240411161441.910170-1-david@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7DE9240014 X-Rspam-User: X-Stat-Signature: p8y18o9fbqkhjiwh6tbptmqjsgnedxbj X-Rspamd-Server: rspam01 X-HE-Tag: 1712870910-811617 X-HE-Meta: U2FsdGVkX19ay6/qHGQ1uZv53/wQLDHM2egjmXNMeGmeTWInAeAJ1D4KTqVvcefT5suCvrFgIKsPknwFrTY8IGQhIr5y7andCtDmydGUEBCM9Ly6gu7LFca2fFFn70lf7nZL6gBYJVllnULTqlapC0VeWW9QbnlwxzCS/dZLpvImPGcbYVj+/iaddlt4DekhwJNvY4GdRQ8zWBmaZ3SWoIiGr/LMsbww4tkuFS4/DuSji+Aa3m5lx6gS1Rk/bwnrKX6hBizJYHphz4HPdq9iR+GeCu3NBr4EDg1R7Nef8zN0Mwj3hOQ8QJ8rThIwJ0lTxrcvcEVDCjQSoquK32s0ZdkT5A/0/1vgiUxF3oxT+VfS/1fH/i4Mq6E7IAoB2zFzmUPyJx+6r9u8+w2wwYALnZQRqk4vBjvV96fmbh6IJN9rJ/xnqQXmNXBczEcD6NOqQiFtz9WpQSK076RUjZrTdmHsOM8Hv4JF9fOWvPGXDxAxEhnWNeItQn9bfsJesj75y6w0sbc85m+H5VEhK2+0P1YKwAAJD/38u68cLl1PQeK6wmYnlYBeYJQDmQZF54iEFajoa90l8l1+l6Btl2EjRkotFT7/CM3C1V6m1fRRj2ZTIubV0FvNrisL2XnZsAwNLZDQQwOhAHhbVwafvjSeWswuInuwzGmUWpUosZqcUIXRAGn/31TvWX2FYUGFgaU/r+618sCI9ndwxNT5I5j0dSGXogIZIB5QVTwSD6oFizw1Y6i+O2IIzQuPx2zwfmYeORCQ37Oss3LksCjlioYFWdQwO6ybPkC1CWyPN3qE9YLjWunJUgkUJO32mC0EeKhy767CSDQBd20/Cg2KilhSHxUgKygRZKDRQxwDzowHWXmzobO3cOM4ebLrF9hRU2odTa+O4Wv1h4yi8479cP9+b8r5Mr76kurc/xLGseQ8n731OF/HUUDunQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 11 Apr 2024 18:14:39 +0200 David Hildenbrand wrote: > This series fixes one issue with uffd + shared zeropages on s390x and > fixes that "ordinary" KVM guests can make use of shared zeropages again. > > ... > > Without the shared zeropage, during (2), the VM would suddenly consume > 100 GiB on the migration source and destination. On the migration source, > where we don't excpect memory overcommit, we could easilt end up crashing > the VM during migration. > > Independent of that, memory handed back to the hypervisor using "free page > reporting" would end up consuming actual memory after the migration on the > destination, not getting freed up until reused+freed again. > Is a backport desirable? If so, the [1/2] Fixes dates back to 2015 and the [2/2] Fixes is from 2017. Is it appropriate that the patches be backported so far back, and into different kernel versions?