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 C1FB2C25B10 for ; Fri, 10 May 2024 22:04:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C2896B0134; Fri, 10 May 2024 18:04:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 173436B0135; Fri, 10 May 2024 18:04:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 03A066B0136; Fri, 10 May 2024 18:04:07 -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 D0B9F6B0134 for ; Fri, 10 May 2024 18:04:07 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3283C1A0445 for ; Fri, 10 May 2024 22:04:07 +0000 (UTC) X-FDA: 82103864934.19.10E3772 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id AD8A14001C for ; Fri, 10 May 2024 22:04:02 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EZfbPt5m; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715378645; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4tCcCmU0a8nOK6SSF/CMC8Yp1EzBol+Xsag+eAgzaCI=; b=F6+jguGBZyHW7IcDOEpTmA801vdbHUE3CDCv/XvkXnl78+/Dh4lr04b2wk08D4jntElkSb IxDKSGQQk5+WClRgBSqNvQ0pfviu29OfC8xAJNVNPQIeSN6G3c7fxvRhsTnF0hbZM/wbny IyLKHiH49O3YBKn9tZgL36iDvwxjbMQ= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=EZfbPt5m; spf=none (imf01.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715378645; a=rsa-sha256; cv=none; b=nbfsSkFWAoytFslml4WrMeztv9Yf6oPtKLPF5vdbs1Gyw8Qn8pfRAtUCpooQtxzWOSREAo qcZno4tqjAYKNoa3TmqckKtPj0p2Vtfj+5nqrcuASqzxBZQ+KJDYjO2v/eSdayk/Fn0p7f 6yz9DQ65qMiPUUhZZ+7mBK8hsdxEDFQ= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=4tCcCmU0a8nOK6SSF/CMC8Yp1EzBol+Xsag+eAgzaCI=; b=EZfbPt5mSMfaxqSRXbo72z1+au Z1tt/iHeJIzH0Q6UCLtu9jb0SCsxZrMIbfGgFwS1BAslBAuL4DN+pUPUHGULxUzzb3q8IS+kKP95y kEg+Hs625N9CIICz9i7vdFBXQ3NHerCVSLG0TMpM/s70gcOzdkQ6lMNdGltKrYQuSyoSkezJGHmUQ d6Axz9oWHvOcTGDuRG5bcrPWxrq6XkCP9NKNohljhIQC64zkrgW+Jv0vfw4dcWx5GPNFI3dKPH3Ma 13TSClOdMDglqZL9+j5LCnUvMPECisuMA3TtoJBvX886kTo3lh9/kw+gDdh9LPPpSRNMpHp5okKrb 4We3CXbw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1s5YLO-000000041fg-2sOE; Fri, 10 May 2024 22:03:58 +0000 Date: Fri, 10 May 2024 23:03:58 +0100 From: Matthew Wilcox To: Oscar Salvador Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: Re: [LSF/MM/BFP TOPIC] Deprecate SPARSEMEM and have only SPARSEMEM_VMEMMAP Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: AD8A14001C X-Stat-Signature: it8y4dpqjrrawazpno4ddma4b3rds5mm X-Rspam-User: X-HE-Tag: 1715378642-99630 X-HE-Meta: U2FsdGVkX18ETNRmvq1nMgH9hzC81R0am0SMbi/DYt/l1ZQI5sd/KYWtbMIMGagmnUJ6BphIGO2kVl4+nMKKnQ1XUWohZBSoy7OMZ4hxKz4DlmuWn3fWE5W2LTk1aA8IyU3dOr8ktKb/iA98iqkweTmqVDIycjkquo6AamDFUQwVJZSMi0SWm+cpa9F2hitEDF3pr3O3OZWb7TuRQVYBa6jqaK425xoD2ae01qqKxOi9BdgCnf1NjWbMA6MqvGjp/Do/5+d7QuiKMUQMxd70OxkKhvoIPFnYMa1z+rEl80aOWuvJtw1YwpMqPnGYW3+OcgN6uUavTv/ke4vI3DEK9f434vBZKB5/tLAeU/Zf/fflZ2JbFp7Ws+GnveNlBHBTs+aTR8YXC1VX9oPgePu6wiKlG2shr9KLIIWh6PJWoquKNkCKZ7MWVjNfHE6yhxrYhW3qOEvM+G1+Zq1uI+VwcfgPZ8+oemOrkTeoP99lr2BOw51bSzaIPUOlELVEXWIjpo9cTsQPYKSPnuLaR1CsUEFh/9zAg6iknfriDJL9lwxaIUP3P3sewz0pMoI/j/TLiUrmqJBrWQGe4Mn7r03F7jWWFl7twTUNrGpM4XnZBywx5w+pnPjrHzrT4ApYkSQmZKG/OW++o/IaIoMerX4ytGfFYR1z6DRFSOhuzBg8rDVG1lPI50DWCZqzOGq5R3phCswif+j9pO0sdGB5gQzVGNiDaRTdL8IAZBUS0bIqWUTZ15uOnGR7fVloKGgRcYf+RQzsfGHub2pirkneUijn6HTrmzILMCArX4iHQM8asnKx4X7zXFCU9FHTrH9ZPEAIwVbJ1OH5F64GF97W+vsPS/sTKXXqInvbHLy5fBbIGLrkLL6G4Rp/5xm9qL6wLV/mNvDtpvKPEAcF5zS8cu2HWL3rlYJqxCeDXfwaLjR+MaF4TkTHU0dOGERW7PN+9FZyg3hJA4Wtgt+dpnMXl/j kfmYPs8y zSspQG6woOYWyyihVW2K9nvZT4XWn1vaW8x/xqiHt4HzG6xwNJb1jXH6tDvI6S+JGbO9uNY94Cl5uCu4JY1Lmst8MOrBeOjdUIGaG4Vi4aYRIJBEltwT+0551LwXtMVJtDZJb9fpNg3NfqhQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000011, 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, May 10, 2024 at 11:03:14AM +0200, Oscar Salvador wrote: > I did some research on which arches use CONFIG_SPARSE_MEMMAP/VMEMMAP or > none(using flatmem?). > > SPARSE_MEMMAP SPARSE_VMEMMAP > arc > arm X > arm64 X X > csky > hexagon > loongarch X X > m68k > microblaze > mips X > nios2 > openrisc > parisc > powerpc X X > riscv X X > s390 X X > sh X > sparc X X > um > x86 X X > xtensa > > arm, mips, parisc and sh operate with SPARSE_MEMMAP but are lacking code for > SPARSE_VMEMMAP. > I think these archs should be the first thing to focus on, to see if we can > make them work on SPARSE_VMEMMAP. > If we can, and when all arches can run on SPARSE_VMEMMAP, we can think of killing > SPARSE_MEMMAP. I'm a little concerned about having this conversation without the affected architecture maintainers in the room. However, I can speak to PA-RISC. Early models have a dense memory layout and we need not be concerned with them. I'm not quite sure about the PA-7200 to PA-8500 ccio based machines, would need to do some research. For the PA-8500+ astro based machines, the 256MB that would be in the range 3.75GB to 4GB is relocated to 67.75-68GB to leave space for PCI mmio. So if you have a machine with 8GB of memory (fairly typical for a J6000 machine), you'd have three ranges of memory: 0-3.75GB 4-8GB 67.75-68GB and I'd like to see an analysis of how laying out memmap would differ for those machines. The PA-8800+ pluto chipset does something similar, except it supports more memory and more PCI mmio, so a 32GB rp3440 would have a memmap: 0-3GB 4-32GB 259-260GB I think this would actually work better as three zones rather than three sections. It might match quite well with the TAO proposal.