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 A079EC77B7C for ; Mon, 8 May 2023 00:23:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C9C146B0078; Sun, 7 May 2023 20:23:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C25256B007D; Sun, 7 May 2023 20:23:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC5FC6B007E; Sun, 7 May 2023 20:23:34 -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 9985F6B0078 for ; Sun, 7 May 2023 20:23:34 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5CCC81204C3 for ; Mon, 8 May 2023 00:23:34 +0000 (UTC) X-FDA: 80765189148.15.BFEC5B6 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf07.hostedemail.com (Postfix) with ESMTP id ACA7640003 for ; Mon, 8 May 2023 00:23:31 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oA41I2ue; spf=none (imf07.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=1683505412; 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=/ndftXZhVS8NkbL8HbwnMScUwIv7+CmBxMuefylBBbM=; b=UaJdx5u2tr4HWH6EQeuqQthIY39OGMDRYSH3UYGHRyLHBS5WhR0u5ylj91bRw0Io12Ozbf zJlQQvK5h1jUZAt6ddQ8cAoSJ3AhC/y8fzHxtT2q17zKs225LZzPyShXw0AON06cDzpOko AU36/5nQ7wPD7gZz3m89iF2lxsj4Img= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683505412; a=rsa-sha256; cv=none; b=w48h596TFaZxoVnQRpvSgWuOHrck5VcEDgpWTa8hpNc1EjOU30mfA48Xj4zYKEb04h+bqD WzDBN+jUBUvKIEmB5DVq0f8JYAUREWJlRTTCXJUUjXck8U70iuysIm91jMu2a3yyfCWn57 RFlYXszk8PjH7leGl94xnHZKFxDk70U= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=oA41I2ue; spf=none (imf07.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=/ndftXZhVS8NkbL8HbwnMScUwIv7+CmBxMuefylBBbM=; b=oA41I2ueadvjJ6e7RvHlhWJPKL XYESV/pKeTuuJj2vUzrB1Y6YQYd6HMnNK+R2brvvK9ia8zNw9mgg3DTWxjyfYZWfgeqsgdM8ql4g+ z8Wm7hI2P92UdVWZcvFp4Uj7RANPiiSwuWmz2pDlP/cNaeoDxfuPlrNNMFYHa1CWvhcWBLW0vFEo8 GcD82uloLtsc69p/R6bw/0CZE8+g31aPLbo9ASmwcBNB2aB8zS8dIJwKbJGPpbzWbU441SA5DhoO3 Mds+11w7Lwpiq8Y8LnxiR2dXe1P0ks3dMN/cFj1VW1K2aHxmYGsVyCyJp2j9T07oJvLAZCKXzvSOP drG4JYnA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pvoey-00DfVg-6F; Mon, 08 May 2023 00:23:24 +0000 Date: Mon, 8 May 2023 01:23:24 +0100 From: Matthew Wilcox To: "Kirill A. Shutemov" Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [LSF/MM/BPF] Whither Highmem? Message-ID: References: <20230507234330.cnzbumof2hdl4ci6@box.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230507234330.cnzbumof2hdl4ci6@box.shutemov.name> X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: ACA7640003 X-Stat-Signature: 5ftjaha58g89x1rcwodi73e5apgsq17h X-Rspam-User: X-HE-Tag: 1683505411-563926 X-HE-Meta: U2FsdGVkX1+361BjBbNumL2PHmmVoyCxb3uKkx1Sn3u3zjx9bMpSD5sWj2UT7hnR4Z6Q8K1QZ3cELhs2nCiUVDenR8Uf3D3RPjUUfmvXiR+I0kspdumrWOTqLfELlmPeMwNeL5sr4KfX+Ek33HXfKXis0pUcqxzAocEtTBY0mwQdcf3vH7TKvaLK/93vcL9m8xRaaszSm+DrMCx2ZpJh3lwOGhvVk8XKaI2wT1bbMbdICJ9ycUFkPjPwvCFrVlezG4KU5/RnMFUBugp9RJA15ldOVz226dRF68cw53040din9m3nH7m29gmEghZDyUZ2aB92RQ710+ZxlKeYm+RQPZJKIXaNbWhQ6ga1YescdpnR7K1sD02d+YHtiEVw948kIuQwDZzpFY8A//fZFh/X5EJ7WxSIrIQ4/FXqwueedTRzQRn121N/k2CFQA4OLCbCI/UjXOCG0MOdz6MmBrrzB6xDQ0aZ+sUjWhCusPuDEGcj//TsTkwhtKlQC3xGOXDHvIPQq0hfqT1b/kefxEpCF0ApOmd3g4Dy1i6rpsWl/+VC8vQ3tsiksgyt6/ekIv2BHcSt9kqGnlpbr/MqANrygHa3THGHzZKGJFXYs9nUU80tMWCpu5g5YrwHj/HHN6fwO+XpU+vFSHJvkEl9u/cLJ0Wl4WY/HbgBr38J/kU2rVVjIhFFAybOn1cMav9xw6bsj0auKu5+GWXyL7v4RVgPVMv7zlvVK1ZhT8hBv/n888IvLi2IH9tx/AagiqxXm2Xum2N9dbfaWnWUepcyEDSQqJLE0nIELTJ11lI9CWSLdaKXqZhSrv+mQnshYiWj/DD4xDPuUpED2Bz9p+FNGshnhD7OpqP2zc0eC/CPy6pxtVW0YSlEersXKNaLbvmEs3oz2+SJkWOtqxbvCRQ5VTDllecjeU1yrpzGiznY3inzHZaW85l/04tdi3eTXkumUX4c2+kW0refExFOHdxKzCe 0nTXQFE/ piLjzkIu/dQW8CjQbE0ef1D5sg3H3FZH/We/O1ZRSlRnTi6q1qj/YpsLNt22B/L3oTW6EKtaZp0i1r4yMmq5GfY85Jl/sGTkkYJGCPcwrM7pfUM5t903yuTyPC0EU+7wY1Xy53s5SuBtqW5DSdk2gtMN2HcjO/oxAPzKcJ/DWJc8XPTqeGK05puC1ng== 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: On Mon, May 08, 2023 at 02:43:30AM +0300, Kirill A. Shutemov wrote: > On Mon, May 08, 2023 at 12:20:42AM +0100, Matthew Wilcox wrote: > > > > I see there's a couple of spots on the schedule open, so here's something > > fun we could talk about. > > > > Highmem was originally introduced to support PAE36 (up to 64GB) on x86 > > in the late 90s. It's since been used to support a similar extension > > on ARM (maybe other 32-bit architectures?) > > > > Things have changed a bit since then. There aren't a lot of systems > > left which have more than 4GB of memory _and_ are incapable of running a > > 64-bit kernel. > > Actual limit is lower. With 3G/1G userspace/kernel split you will have > somewhere about 700Mb of virtual address space for direct mapping. > > But, I would like to get rid of highmem too. Not sure how realistic it is. Right, I was using 4GB because on x86, we have two config options that enable highmem, CONFIG_HIGHMEM4G and CONFIG_HIGHMEM64G. If we get rid of the latter, it could be a nice win? Also, the more highmem we have, the more kinds of things we need to put in highmem. Say we have a 3:1 ratio of high to lowmem. On my 16GB laptop, I have 5GB of Cached and 8.5GB of Anon. That's 13.5GB, so assuming that ratio would be similar for a 4GB laptop, it's 5.4:1 and storing _just_ anon & cached pages in highmem would be more than enough. (fwiw, PageTables is 125MB) Maybe there's a workload that needs, eg page tables or fs metadata to be stored in highmem. Other than pathological attempts to map one page per 2MB, I don't think those exist. Something I forgot to say is that I do not think we'll see highmem being needed on 64-bit systems. We already have CPUs with 128-bit registers, and have since the Pentium 3. 128-bit ALUs are missing, but as long as we're very firm with CPU vendors that this is the kind of nonsense up with which we shall not put, I think we can get 128-bit normal registers at the same time that they change the page tables to support more than 57 bits of physical memory.