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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E17E0C4BA24 for ; Wed, 26 Feb 2020 21:02:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B934024679 for ; Wed, 26 Feb 2020 21:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727576AbgBZVCL (ORCPT ); Wed, 26 Feb 2020 16:02:11 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:46177 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727466AbgBZVCL (ORCPT ); Wed, 26 Feb 2020 16:02:11 -0500 Received: from mail-qv1-f49.google.com ([209.85.219.49]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MlNcr-1jqJjw0fjZ-00lmUf; Wed, 26 Feb 2020 22:02:09 +0100 Received: by mail-qv1-f49.google.com with SMTP id ek2so510396qvb.0; Wed, 26 Feb 2020 13:02:08 -0800 (PST) X-Gm-Message-State: APjAAAX0hEivxzwSz6t9taQ1csuTcF/zcaB0EJ6X0uDf1sl13W8oIjLL U2TiM2I4J3oNoCpbLdvHF01vZvwexH54w5qt5H4= X-Google-Smtp-Source: APXvYqxhHS9U3+N/7qg1V3h6/lWCEHWUtHJQtbK71iP6fx7l2VUQMHsb2aYbd6SCMc7GfTj4m50SkWIR7eOfBWBERJg= X-Received: by 2002:a05:6214:524:: with SMTP id x4mr1146649qvw.4.1582750927983; Wed, 26 Feb 2020 13:02:07 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> In-Reply-To: <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> From: Arnd Bergmann Date: Wed, 26 Feb 2020 22:01:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Santosh Shilimkar Cc: Russell King - ARM Linux admin , Linus Torvalds , Michal Hocko , Rik van Riel , Catalin Marinas , kernel-team@fb.com, Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , Andrew Morton , Roman Gushchin , Linux ARM , Kishon Vijay Abraham I , Santosh Shilimkar Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:B0z8MNizJ7kia9aTxiE6iXCBlswXi3zwEcqfTJHoVMKZ6ErYXbE gp9J9teZYve2caR/jKAzBeFbWXOokwclyrbishs2Iowivr/BaRrXg0S1jTYEs0UMII1ZQ+Z uvap5jNCyXnghvWmjal06Ip9spD1yKLFco46EMboXYOFM88ItGGFkvohGR11QxVAUb0ACwR YWTOsWFaAPPbgdMGauv/g== X-UI-Out-Filterresults: notjunk:1;V03:K0:K2vDLtCaXnw=:PNYIHzWGGEEBd0aqVSb3CV zOkvHEntYYIhHdS/oR5ZUVIUw8DEtHTE6HvnGR/7lxSWwEv7mEdD3serbMqm/exblu0v+Dxpm UbZg/MYcm2bKh+EpWRDicVrz8UuL8/qvI03EHJdkwvNe2TCsO7whgglwvwUjLbYfQ8rJHfw/+ nt1l6uxEQG5F1qfxQpmJ2Tec3ICc5jLJKj3oKRiqd1y98DJoUqy8Jp+aX6P2Gr3b4pCwWiLqF YSvlHvXfcXYRWAln5Ue9NqubcHEJsi0kKUf41Ww/4i0audXtoN3h8PqbxD/OECmmfWhmBjctg SZFgaU1Eiyv8Q1/zD4Pq2j12vjFOUry6PdweK0g34Ypa2DmKXRw94Hfa4gk87uCNcCiY07QZR q4TM3Mg8RYIL8oeOt2nGCF22okBN9WwjdTiynzSdE3fUtjXTIRibRXFiSmYgngGGM/7U3o0sG ZdwPALqYomcrcbqoRHDX8H7Sj8iW+nV9jvsw9ArdeBlTqwgo+waI41JcgVpejafPbCTcndMo0 Z+Zasl9MdpaNPhuc+DiMCMOuVCOgfR4XersXgqj68zEoFtApJFYYEds8qtxrSJk5ZE+9NR9h2 r2pb4/NiUt53pefOd1E5/vWHj+oMUT10tO6Deodcff6hqzUo4dDltXDFfFdlcruH6BJgOfISY QOgMMxfvYwF2fvLpQzxx6SouFrsnJlK+2em/Mfs7JW3NMrGCRXvyWPQ6izuQu7DZKtpWYheU6 KR1Whpy9BbahJ54LuwWfzWasGDIA68udw1Pw3Jt+ZAd2OG2JHhxJPyrUj8/rfBiiXbe+hILY5 tzzqHQqyovwxKjvRQ1gyzP4H+vtTtPnr48ON81SMHaJVj4TX7Q= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 26, 2020 at 7:04 PM wrote: > > On 2/13/20 8:52 AM, Arnd Bergmann wrote: > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > wrote: > > The Keystone generations of SOCs have been used in different areas and > they will be used for long unless says otherwise. > > Apart from just split of lowmem and highmem, one of the peculiar thing > with Keystome family of SOCs is the DDR is addressable from two > addressing ranges. The lowmem address range is actually non-cached > range and the higher range is the cacheable. I'm aware of Keystone's special physical memory layout, but for the discussion here, this is actually irrelevant for the discussion about highmem here, which is only about the way we map all or part of the available physical memory into the 4GB of virtual address space. The far more important question is how much memory any users (in particular the subset that are going to update their kernels several years from now) actually have installed. Keystone-II is one of the rare 32-bit chips with fairly wide memory interfaces, having two 72-bit (with ECC) channels rather than the usual one or two channels of 32-bit DDR3. This means a relatively cheap 4GB configuration using eight 256Mx16 chips is possible, or even a 8GB using sixteen or eighteen 512Mx8. Do you have an estimate on how common these 4GB and 8GB configurations are in practice outside of the TI evaluation board? Arnd 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04026C4BA21 for ; Wed, 26 Feb 2020 21:02:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C01962467A for ; Wed, 26 Feb 2020 21:02:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C01962467A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4D5386B0003; Wed, 26 Feb 2020 16:02:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AC6E6B0005; Wed, 26 Feb 2020 16:02:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39B166B0006; Wed, 26 Feb 2020 16:02:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id 205FB6B0003 for ; Wed, 26 Feb 2020 16:02:12 -0500 (EST) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E2441180AD802 for ; Wed, 26 Feb 2020 21:02:11 +0000 (UTC) X-FDA: 76533500862.16.lead31_8783f3848145a X-HE-Tag: lead31_8783f3848145a X-Filterd-Recvd-Size: 5551 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Feb 2020 21:02:11 +0000 (UTC) Received: from mail-qv1-f51.google.com ([209.85.219.51]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.145]) with ESMTPSA (Nemesis) id 1M7bJ5-1j40Ts1lgz-0085Ax for ; Wed, 26 Feb 2020 22:02:09 +0100 Received: by mail-qv1-f51.google.com with SMTP id dc14so481265qvb.9 for ; Wed, 26 Feb 2020 13:02:08 -0800 (PST) X-Gm-Message-State: APjAAAU88bdGLYWnWmSlDJgZOiN9p9ChLRUfG3Tymw9GkbQ/9etUxeAL 5eYMeX1k66ce2rJu0qfAr6AVIKmbO+Yp+kNy8Yc= X-Google-Smtp-Source: APXvYqxhHS9U3+N/7qg1V3h6/lWCEHWUtHJQtbK71iP6fx7l2VUQMHsb2aYbd6SCMc7GfTj4m50SkWIR7eOfBWBERJg= X-Received: by 2002:a05:6214:524:: with SMTP id x4mr1146649qvw.4.1582750927983; Wed, 26 Feb 2020 13:02:07 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> In-Reply-To: <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> From: Arnd Bergmann Date: Wed, 26 Feb 2020 22:01:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Santosh Shilimkar Cc: Russell King - ARM Linux admin , Linus Torvalds , Michal Hocko , Rik van Riel , Catalin Marinas , kernel-team@fb.com, Dave Chinner , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , Andrew Morton , Roman Gushchin , Linux ARM , Kishon Vijay Abraham I , Santosh Shilimkar Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:DQ9xr8vifKkG68bvcEApENzqnXP2ABZo/7BLY3QyT7mgaNRtNfr Pr7M5J9Syp5o4Y5vIAvAYPsxKWswJowobqpeAT0n8M4dICu7ItG8Jl+HOpJBt2Gr93UQivs B+EhC9WQg2zcd+Vul34Xq+Cp8PjwkKPizOaFxvktSA/SWJV8d5KAJVsUpBR6XluX31AtDba O2q7iqkgWG8tgc8FvSpuA== X-UI-Out-Filterresults: notjunk:1;V03:K0:6hj5NDE7UcU=:cQIFWYh9JpJweFh3CYl6S+ 7frFrp3VURJhnHmWtXSW5YarXcE7pc2ZkyjCitWrbtTPGhht06tm9Sys5rF9BMNBoC1ar57+v UQ1atl9InoyYzM5ov/J3Wsm2s6S4cDQSc3IYvrQfqfCjV5MlRZCvTg4omTcCDVWaFk3C53j76 w0cxYKXx0WLCWrBBUCXZpmiJPVm4C5Q9O/dwkco/LEaeY5Xx0e4CUV+xkKFDRCOZlV0YKYuY9 W0bNQuk3scxJOdIwkw7tLQQgGkcjtQTPOOyK+jD7LEDElv3rqVvxp4VlipStzr7picA8LbIps kzBwL5otsikORM4Z1WkXxbQBD+1A5zkyxq7A8OMJXm8vxk9cPPEAPCt2Ii6l0fPsI5hrZ1vkd qNbLZQwUmNvjqWjh0NpiwC567L3798xleu2BvMmYwDt+xSCjhS5zHHy9zowGlOf1hJDmvxtCR idBUiTBfjLFzv5JA66ENTaWzO6sknj89wTHweL9hraQoIClvlngTDgmom6DgY0QoPmeIxnhou q/KQE8R4yq7MpGNwGnkZBP5MBLjvvgD6EfY2sNnou4UzZOM0Yihd3KHNOJ9U3FOKKqcviE7zg WN/rnng887wNO7LKhyFpBDDfFE/5TN3uXqyOWmP2+UeNsEeVWUBTbmjTIXO536oZgKVISm2Xw asYo2jxMPBamlVKdj1tJg7l3o+oiIeGNwayqfOyzRFHOUBZjDzD8AJTeH+/O833e1580eB4vo pS1fU6K/tdXXXf3oJHX2t3vR7UKIAUAE3OkAZgNR3ACX1k7a6Us47wH6TiV9R8ovHiv/xTBHj 0pbTagYAln+qTuqy/ZfyX36Wopbr74lk0gh2N4qGd5/uP4DEBQ= 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 Wed, Feb 26, 2020 at 7:04 PM wrote: > > On 2/13/20 8:52 AM, Arnd Bergmann wrote: > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > wrote: > > The Keystone generations of SOCs have been used in different areas and > they will be used for long unless says otherwise. > > Apart from just split of lowmem and highmem, one of the peculiar thing > with Keystome family of SOCs is the DDR is addressable from two > addressing ranges. The lowmem address range is actually non-cached > range and the higher range is the cacheable. I'm aware of Keystone's special physical memory layout, but for the discussion here, this is actually irrelevant for the discussion about highmem here, which is only about the way we map all or part of the available physical memory into the 4GB of virtual address space. The far more important question is how much memory any users (in particular the subset that are going to update their kernels several years from now) actually have installed. Keystone-II is one of the rare 32-bit chips with fairly wide memory interfaces, having two 72-bit (with ECC) channels rather than the usual one or two channels of 32-bit DDR3. This means a relatively cheap 4GB configuration using eight 256Mx16 chips is possible, or even a 8GB using sixteen or eighteen 512Mx8. Do you have an estimate on how common these 4GB and 8GB configurations are in practice outside of the TI evaluation board? Arnd 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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44696C4BA24 for ; Wed, 26 Feb 2020 21:02:19 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 121F324679 for ; Wed, 26 Feb 2020 21:02:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="K9Krat3p" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 121F324679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arndb.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=0TOSm2y0f/etPnFQ84P8foCDrU3Cooh1hLkNBvqHUoo=; b=K9Krat3p+go1Xp OPWMuSFSw8+Fm3zLuJCG4TGw7eIxxexq8r9PWPNXLeFxYUtjEtdFvLuU7e/5XEPIhpkIVKRcz9juE hf/1/k6Qgok8a8dtkIyxz/C8vHkl5u3WROD1/BrXe15sIvx7z5s1PpRfLKTOuxIyG7hvOm5dNAxuO rQmJXq2+UgvjPXUY8J8JWvBoJjOPTzuJbrOriIjHYi246NhW3Z/cvqTVO061szaaYhNiTQrLm5ZIW qFCddyERvKTHP07TfqOpcKtk0/6qoSEaTDhqcOqIgKwetcEi8y0vECyeSdnNBOPoy4xO0KyG7aSpu VxhuNinXxczZ0KMByRGw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1j73ow-0006Bf-IJ; Wed, 26 Feb 2020 21:02:18 +0000 Received: from mout.kundenserver.de ([212.227.126.130]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j73ot-0006A9-8z for linux-arm-kernel@lists.infradead.org; Wed, 26 Feb 2020 21:02:16 +0000 Received: from mail-qv1-f51.google.com ([209.85.219.51]) by mrelayeu.kundenserver.de (mreue009 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MtfRv-1jPGf80sGN-00v5BG for ; Wed, 26 Feb 2020 22:02:09 +0100 Received: by mail-qv1-f51.google.com with SMTP id g16so493917qvz.5 for ; Wed, 26 Feb 2020 13:02:08 -0800 (PST) X-Gm-Message-State: APjAAAVDZCUwSYl6w2Ao1O2KIiL5NFJeGxku+FDKb+BcuLVkF8nJJSdl Fp8/6sCuVDbK/JlJuG6SarGyX0FTBDs13BMfauQ= X-Google-Smtp-Source: APXvYqxhHS9U3+N/7qg1V3h6/lWCEHWUtHJQtbK71iP6fx7l2VUQMHsb2aYbd6SCMc7GfTj4m50SkWIR7eOfBWBERJg= X-Received: by 2002:a05:6214:524:: with SMTP id x4mr1146649qvw.4.1582750927983; Wed, 26 Feb 2020 13:02:07 -0800 (PST) MIME-Version: 1.0 References: <20200211175507.178100-1-hannes@cmpxchg.org> <29b6e848ff4ad69b55201751c9880921266ec7f4.camel@surriel.com> <20200211193101.GA178975@cmpxchg.org> <20200211154438.14ef129db412574c5576facf@linux-foundation.org> <20200211164701.4ac88d9222e23d1e8cc57c51@linux-foundation.org> <20200212085004.GL25745@shell.armlinux.org.uk> <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> In-Reply-To: <671b05bc-7237-7422-3ece-f1a4a3652c92@oracle.com> From: Arnd Bergmann Date: Wed, 26 Feb 2020 22:01:48 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Santosh Shilimkar X-Provags-ID: V03:K1:2Lig7L6onp01s+wxRanWjHQNmnp4m/teflFbevNCW8Ug0YQVyOX 6lV8qCfe54zG7+S+Uh6rqVCZyH2UJsdWr7WTSuFNlNpG/ueIOEV4U4SkIsmHNcgKqE6UV8s XdhDb+GPCVAxAv2VpGHPRr0FGA7lX5VMRNwGLB8mxwoOLDxziWTCTzeq6/yvfdUdtQfVPXX mXXaJU8PooYJJVzoXPtQg== X-UI-Out-Filterresults: notjunk:1;V03:K0:/7bi7l9cIYo=:TY2kYnzub4IvPMtSMoHbpO Goz3Bgs155u2/1lSuGI5WaJQ/q+C/vl0SkA5WXmSHUGCi76yGmW35QeVXUso0bmTkX/7/H5w3 /TRgli5RQNUlxpG7Sl7kAyIgKIzHT5JI1T56H1w4mlaSfiYxExSFzILzSnDgv5920iNWfNNca NOf+Pyt9VeRe014xSZvDSsQaQJjpM0We71BsyDdD6QmW6TH3+NRAJtfhb4rGcuV0CzbmborXh y8f7hr4MXqAHURmFjqLDSpTQQF+iMfacXcAA9dRk4c2Xtu5iW0PgqYpH8Xp+m5lqfdPLo+ftT 6AyULAI94zPimNlADWDW5fNbAaIZThkrLSu4+l1KOJDIvQBW2Hoin5/gtPsKmX1XVs7LUsr/5 5F4v0Ru/x2+Y5UgwmGcksl0dGTOxf7MBrdNFYHRu1csxvyQ4Z1hbraOf/JlIlrHO6o3zskhHF yGlBDCP5L/IPZPu0tLs79iZe4gZtGoUu9o1BR1dH43BRJTKOOSjS2DXVc6P5r37lJW8u/Ml0z ZksMjup1DYOhqjDrDjWiQRAB2nA/a5O1FIamkdpn6LwUx5aWXxx+n0OWR5u5xKgzGGN+6uAU5 60WeR17byHGoXPwzr8lKxnJY8BXIVaGDN+tEiM6D3GmxGf9F3khE2BQDIviBr/yt/hRn18bbi UMCKVOcw9JG1AeMDx1FWTfEiFQKPS+sNA1Morn+K/e/RjwEpAeAqlZHNDwS3l+cBAUyuXP/T8 TCp8bRz+nsschmFvpdrwmaSqCLTQtcx82tsx6J1ul0qe0SnzcmXlB5xDn92q+nDVLEz8DTW87 Xsg18/uPjz2KELm4rMhJGSELCavddtXuk/R298U9yCTkE+UQNk= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200226_130215_606585_D2E62880 X-CRM114-Status: GOOD ( 15.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux ARM , Michal Hocko , Rik van Riel , Catalin Marinas , Santosh Shilimkar , Dave Chinner , Russell King - ARM Linux admin , Linux Kernel Mailing List , Linux-MM , Yafang Shao , Al Viro , Johannes Weiner , linux-fsdevel , kernel-team@fb.com, Kishon Vijay Abraham I , Linus Torvalds , Andrew Morton , Roman Gushchin Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Feb 26, 2020 at 7:04 PM wrote: > > On 2/13/20 8:52 AM, Arnd Bergmann wrote: > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > wrote: > > The Keystone generations of SOCs have been used in different areas and > they will be used for long unless says otherwise. > > Apart from just split of lowmem and highmem, one of the peculiar thing > with Keystome family of SOCs is the DDR is addressable from two > addressing ranges. The lowmem address range is actually non-cached > range and the higher range is the cacheable. I'm aware of Keystone's special physical memory layout, but for the discussion here, this is actually irrelevant for the discussion about highmem here, which is only about the way we map all or part of the available physical memory into the 4GB of virtual address space. The far more important question is how much memory any users (in particular the subset that are going to update their kernels several years from now) actually have installed. Keystone-II is one of the rare 32-bit chips with fairly wide memory interfaces, having two 72-bit (with ECC) channels rather than the usual one or two channels of 32-bit DDR3. This means a relatively cheap 4GB configuration using eight 256Mx16 chips is possible, or even a 8GB using sixteen or eighteen 512Mx8. Do you have an estimate on how common these 4GB and 8GB configurations are in practice outside of the TI evaluation board? Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel