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 D5AFDC072A2 for ; Fri, 17 Nov 2023 13:00:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E26A6280011; Fri, 17 Nov 2023 08:00:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DD5F0280008; Fri, 17 Nov 2023 08:00:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9DF3280011; Fri, 17 Nov 2023 08:00:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B98AE280008 for ; Fri, 17 Nov 2023 08:00:26 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 5CCA6A0D9E for ; Fri, 17 Nov 2023 13:00:26 +0000 (UTC) X-FDA: 81467454852.06.C55CB6E Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf07.hostedemail.com (Postfix) with ESMTP id 8B7AA40022 for ; Fri, 17 Nov 2023 13:00:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=kJJCUDZO; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf07.hostedemail.com: domain of gerald.schaefer@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=gerald.schaefer@linux.ibm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700226022; 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=EpvSzij4IZzTP17DO04zM9nABo0pm+CaKulGeqPxxN0=; b=U5h1cTKGOrkszvX9cSauOP3BgPLsrDkc2TKnEwM85pCuyr2VyPS4j32o2yK0k1CNV6Jq14 Gk2qIrJdECuz59avjqPsiq8tu4owvGRHQ+0OjVfh7htafC1Qulscir41FjBs5eOgpxdkgs Mch/dwrMOaVszjPsRGNw4NpF8luiYug= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=kJJCUDZO; dmarc=pass (policy=none) header.from=ibm.com; spf=pass (imf07.hostedemail.com: domain of gerald.schaefer@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=gerald.schaefer@linux.ibm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700226022; a=rsa-sha256; cv=none; b=NfLaOTmoQZ+DvETCC0SPrTqCdkA5zer3F/Q7GjZcHd78c3sRSNhSjCmKtANCpaT2bpr6ef A7sEP6xRPGMRryWpvtEKCoCt0QUzldPATviYneVZ7LUcASvBB693KzK3I1qDn+aqmrgIgU kD9LYbNOxGjWOYyWVG/FNttOye4zl2s= Received: from pps.filterd (m0353728.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3AHCkEoG016411; Fri, 17 Nov 2023 13:00:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : cc : subject : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=pp1; bh=EpvSzij4IZzTP17DO04zM9nABo0pm+CaKulGeqPxxN0=; b=kJJCUDZO9RDM3R4qNFVDulDl8JZJjIXKWgEiljzpUrUCNcab7dAC/rOH6V23pzxyQjGG awv2Jtz7VCCB67aeuT8vzmxygmM42x/BDfyBfbTxHKr3Mq/JKeNJjCiEYbVNbtZ3O7nH duI7eEe9lUWrzxGukG1c0gwPM8fpRVJofcLHLCMIBAztHVFIQPPIF3jAyPDi76j0ynIS 2HMWw6SABBP2DNcXRCDYfyWNjHPO5UqfaWCtpMYkzRWvDLGfpvZYY2SFWqVgc7i+dFQ9 urrElO1Tu7fsPPACYHjZy1VCL3fUnChkMussq+qETyquyxlBfOXmGwKWufEiQs5n0Rlb VQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ue84f133h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 13:00:17 +0000 Received: from m0353728.ppops.net (m0353728.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3AHCl0qS023197; Fri, 17 Nov 2023 13:00:17 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ue84f131p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 13:00:17 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3AHCnC36018248; Fri, 17 Nov 2023 13:00:16 GMT Received: from smtprelay04.fra02v.mail.ibm.com ([9.218.2.228]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3uakxteaxk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Nov 2023 13:00:15 +0000 Received: from smtpav04.fra02v.mail.ibm.com (smtpav04.fra02v.mail.ibm.com [10.20.54.103]) by smtprelay04.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3AHD0DVQ34800068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 17 Nov 2023 13:00:13 GMT Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0C04020040; Fri, 17 Nov 2023 13:00:13 +0000 (GMT) Received: from smtpav04.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F35A520043; Fri, 17 Nov 2023 13:00:11 +0000 (GMT) Received: from thinkpad-T15 (unknown [9.171.21.29]) by smtpav04.fra02v.mail.ibm.com (Postfix) with SMTP; Fri, 17 Nov 2023 13:00:11 +0000 (GMT) Date: Fri, 17 Nov 2023 14:00:09 +0100 From: Gerald Schaefer To: David Hildenbrand Cc: Sumanth Korikkar , linux-mm , Andrew Morton , Oscar Salvador , Michal Hocko , "Aneesh Kumar K.V" , Anshuman Khandual , Alexander Gordeev , Heiko Carstens , Vasily Gorbik , linux-s390 , LKML Subject: Re: [PATCH 0/8] implement "memmap on memory" feature on s390 Message-ID: <20231117140009.5d8a509c@thinkpad-T15> In-Reply-To: References: <20231114180238.1522782-1-sumanthk@linux.ibm.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: _8IgcNhl1Q3EjoPKWdhOS6W_f4Yeuo_X X-Proofpoint-GUID: wzc4NKEfP-r6KnWa28LVOQQokw-7Hbrr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.987,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2023-11-17_11,2023-11-16_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=51 lowpriorityscore=0 suspectscore=0 priorityscore=1501 adultscore=0 phishscore=0 impostorscore=0 malwarescore=0 spamscore=51 mlxlogscore=-1 clxscore=1015 mlxscore=51 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311060000 definitions=main-2311170096 X-Rspam-User: X-Stat-Signature: sosayxz4648xokzri3c8uhekbbhmbt4h X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 8B7AA40022 X-HE-Tag: 1700226022-990287 X-HE-Meta: U2FsdGVkX1+3AQI7uaoG+5bQWCuLOHLk5JBMddeESKelDyErUW+2HEt+anZZnLzC6+Ia9A/Jx4KUE3tl8pMVnexh0vGwy8oLf5F5EmhKXTos2pTVzngs+zO/ZYhGYV0MQ4O1v+9+aOq9450ktsvUXnslIoQJp78xEMNAJmJjEvf+ljZVsrEcF/mCEnUhFvpYst5ZV1sIwF6ZKWcxUsR867tMbXNRjzjaYv2wbsiv9QACFh0Bk+BwEUnI6C1PhKsoUM1bF052DDEX8xDHYOhuXU0YJXUchUHkOMaUMcmdqBhRJYe+nmhENhGbW0Mleo5cBvMyatxcR2TzdObmWGKGjEPXcPZlZ+8N/WKW6SoqEX0XHu2ea61mrC58XuNrrPgunGR+ByK4bLbajcabAdQmzNrwp8nE5RI0BimIRdzVdVfzQDFk6bTsUIOOmq6RVbGWSUmVy/XYi+1xFAbmeH1jiCjwDmscINwYsd+9+prh/C+7qc5qtXfUdxsrhdGhCYW37IOoFLpCTOhOQZIWzGlYWk1EGbF3rMNh69U6u6KiirrL/+5AcJ1vnFGd/Nd3VEr9Fh7plZBmGC97zPwhN/woCi28fjlOBWkEziZRpX0X2RwA/hJ0/uSZ6Et3tk+AezalM0f3iTcSTLLH+BcGqPWPLGhh7h26wMTzeqTmLrQE0bSyZQOowisr6Hqn66tM4hmzxeQEychdmwhsjh6lX3W6o3A/lP2vWqo1oJU2X4kK0i99rS8Ehytc/KAEqqF44mQUiAEDsYUgqvoE5uFqPTouG917h1ZJWCxYEAOHVHY1OCt5j3ahDHAjMEs03JptU/83MJMoYI9B/L03UrPUnuwukvNoqex6KLBHLC7AzqSeqCU2YlV2gSXkge/S1QDM1Ysv/cmVw9CkmsjlWxf3Ux5aCjffbeJjydo5J1U0eLa2rsRDsM+s3l8bJj+YvnPMwmNGiVnN3KeV6xWvampBj6m yr/ayuhx Or4DMzVOS3dDoeJ9tvCMLEIpJHuuDi8jbtMnuc1dOiK6q55yC3MmohL8l3X5IiSjhzcjCKvTXU1+D++LKtDiUX5D3ovhlQRzq0kB4+bPdRBCrkpIIA/kU6K1bP0HCvYfHNArOE+xxtS6uh8fXg/lHxghmIIWno+At1B3h0dqy3UojjW/oa1i/O+HsJwixcoerDMEo5E5x/+tINqbhg9nquficjXFLcwyef65rrc0tn7dAuMjykBt/4q970qpnqgeEJC65XsIdsPKp9yBrm1V8VQL1cfL0/+gwdK3a 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 Fri, 17 Nov 2023 00:08:31 +0100 David Hildenbrand wrote: > On 14.11.23 19:02, Sumanth Korikkar wrote: > > Hi All, > > > > The patch series implements "memmap on memory" feature on s390 and > > provides the necessary fixes for it. > > Thinking about this, one thing that makes s390x different from all the > other architectures in this series is the altmap handling. > > I'm curious, why is that even required? > > A memmep that is not marked as online in the section should not be > touched by anybody (except memory onlining code :) ). And if we do, it's > usually a BUG because that memmap might contain garbage/be poisoned or > completely stale, so we might want to track that down and fix it in any > case. > > So what speaks against just leaving add_memory() populate the memmap > from the altmap? Then, also the page tables for the memmap are already > in place when onlining memory. Good question, I am not 100% sure if we ran into bugs, or simply assumed that it is not OK to call __add_pages() when the memory for the altmap is not accessible. Maybe there is also already a common code bug with that, s390 might be special but that is often also good for finding bugs in common code ... > Then, adding two new notifier calls on start of memory_block_online() > called something like MEM_PREPARE_ONLINE and end the end of > memory_block_offline() called something like MEM_FINISH_OFFLINE is still > suboptimal, but that's where standby memory could be > activated/deactivated, without messing with the altmap. > > That way, the only s390x specific thing is that the memmap that should > not be touched by anybody is actually inaccessible, and you'd > activate/deactivate simply from the new notifier calls just the way we > used to do. > > It's still all worse than just adding/removing memory properly, using a > proper interface -- where you could alloc/free an actual memmap when the > altmap is not desired. But I know that people don't want to spend time > just doing it cleanly from scratch. Yes, sometimes they need to be forced to do that :-) So, we'll look into defining a "proper interface", and treat patches 1-3 separately as bug fixes? Especially patch 3 might be interesting for arm, if they do not have ZONE_DEVICE, but still use the functions, they might end up with the no-op version, not really freeing any memory.