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 D10EBC3B1BF for ; Sun, 16 Feb 2020 20:38:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 975CA20729 for ; Sun, 16 Feb 2020 20:38:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727742AbgBPUiq (ORCPT ); Sun, 16 Feb 2020 15:38:46 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:55135 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726020AbgBPUiq (ORCPT ); Sun, 16 Feb 2020 15:38:46 -0500 Received: from mail-qt1-f170.google.com ([209.85.160.170]) by mrelayeu.kundenserver.de (mreue011 [212.227.15.129]) with ESMTPSA (Nemesis) id 1MOzCW-1ipDBY1olw-00PNZ6; Sun, 16 Feb 2020 21:38:44 +0100 Received: by mail-qt1-f170.google.com with SMTP id i14so3495619qtv.13; Sun, 16 Feb 2020 12:38:44 -0800 (PST) X-Gm-Message-State: APjAAAVQB1ZFqPArWJxfpy4FpDX1QO9LhlLggNsaxKs94ip8V/b368LQ TiKErzLRSXkRtCLKgcAMFtLXd3BGz4ysNm2OnoU= X-Google-Smtp-Source: APXvYqzGbYZ4aYpEY0TUWZN5AxiKnI5sM7fs3pGtoCEgh1lCGT2r9R0o04dDMj4EezabIIFY8gGD+8mZfxHFiF3300Y= X-Received: by 2002:ac8:3a27:: with SMTP id w36mr10771015qte.204.1581885523228; Sun, 16 Feb 2020 12:38:43 -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> In-Reply-To: From: Arnd Bergmann Date: Sun, 16 Feb 2020 21:38:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Chris Paterson Cc: Geert Uytterhoeven , 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 , "cip-dev@lists.cip-project.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:gZxUUnC0/X551f/KUXxXG4ss9wKBh5msR+xhojKXYS/iO5TX7gk O/rtvx0vGNDeDzfLKmXEY7KuXuzu6OTPM1VaTDkxEuXBIFHgdnmgPDth+HOE8s9fC31Bp5Y lMs5YGUBVi6Mi8CTrj53jHgJemDj0khciXVQDEx2mCjcPC+poBoXoEkM2E2FGteEMEYAkFL T7JXvloaDe4GtZzauy3kA== X-UI-Out-Filterresults: notjunk:1;V03:K0:x/TUiPaEJdA=:YqkHjNVh9qsbDacAgIEJ3A 8Keqiv3TPpTAyvzlkFHOVAaw16hGQqCAvh3ZpFda2UYn3U9xNVNzIMIW3mnQWFj34QGMEXsiA uFmB8UQQZr7qa0o/J1UbP502x5tTo542lyGzInP7EYtAlfOAaYoleGX1zrPq2PQ6rd3sXtU+X lc3RjDfbaKmhueN2R1gw/8QY9kOTqn0DwLfZyDIunV7GU1Hjwwy64pYuwhcj3Mhq9tGF/CpNG kV6N80IcqMmKgrGRKudWnxa0xYV8NEGvDE6kYG3NH+iXW4EfGKZHjObNuf9iSrk8fyj+O+NG7 ACAmz3MDRqpCZ90Q1V5Zd4J+v42HI7g2zImvhmrOZa+gQgGqw47+7Zdpr2MzxaQ/NJLamZ64C u9vCLATX5Mf3UO3eNN//0ZAznM4dS83XYGO5fTxEd1tyldf3MKp0HoOyin+TWJ/y9dz4e9XgF 7SznfrvnVkCum76q1I2N82TaM4qZQ7WXqN/Q6w8Oc10n0Qzvedzvln1Hzqgpmki3ZM1fEWFN7 qqsJ+ZVvEKYFC2IAB74rqaVVCqUmVQWT/eJQdrRokT7vMfmJmBRQ/KDWuTSIefsVnktBqHSHW l9ripVws+aVcD1HGijn4cjz5x1SvGcfSwqz0ReEnrc81U+07IRlZlY5rJqZnEp1bXd+8tzrhr QDJynW8XRKKQKw1cvUqIN/4tqqAd5E1U7oxFIEaYk/LNUpp2gAhG5EJ3rrwg+aLKR8KcTCr8h 0eXVjzKbqvEt8gYpo6Wv+ZCP+cyLf/l0samyt7tWmOTbuUtrSZwH9fK+QzZ9hCAeFwedb9Pr8 OKXc+U7bUoDuCLcJF100zQrEky4V/kO0ehn1YJort+zzNnhitY= Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson wrote: > > Hello Arnd, Geert, > > > From: Geert Uytterhoeven > > Sent: 16 February 2020 09:45 > > To: Arnd Bergmann > > > > Hi Arnd, > > > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann wrote: > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven > > > wrote: > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann > > wrote: > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > > > > wrote: > > > > > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one above > > > > the 32-bit physical limit. > > Yep. One example is r8a7743-iwg20m.dtsi. This one has 2x512MB, with half above the 4GiB limit. This means it needs LPAE to address high physical addresses (which is fine), but it does not need highmem if one uses an appropriate CONFIG_VMSPLIT_* option. > > > Good to know. I think there are several other chips that have dual-channel > > > DDR3 and thus /can/ support this configuration, but this rarely happens. > > > Are you aware of commercial products that use a 4GB configuration, aside > > from > > > the reference board? > > iWave Systems make a range of SOM modules using the RZ/G1 SoCs. > I believe there are options for some of these to use 4 GB, although 1 or 2 GB is > used in the boards we've upstreamed support for. > > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1, > but I'm not sure of the details. Both iWave and Emtrion only seem to list boards with 2GB or less on their websites today (with up to 15 year availability). My guess is that they had the same problem as everyone else in finding the right memory chips in the required quantities and/or long-term availability. iWave lists "By default 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory expansion support." on some boards, but that doesn't mean they ever shipped a 4GB configuration. 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 790C8C7619B for ; Sun, 16 Feb 2020 20:38:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1238B20729 for ; Sun, 16 Feb 2020 20:38:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1238B20729 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 7E2016B0003; Sun, 16 Feb 2020 15:38:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 790A26B0005; Sun, 16 Feb 2020 15:38:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 681006B0007; Sun, 16 Feb 2020 15:38:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0092.hostedemail.com [216.40.44.92]) by kanga.kvack.org (Postfix) with ESMTP id 528B16B0003 for ; Sun, 16 Feb 2020 15:38:47 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E7F018248047 for ; Sun, 16 Feb 2020 20:38:46 +0000 (UTC) X-FDA: 76497153852.04.fowl11_4c973b17f820b X-HE-Tag: fowl11_4c973b17f820b X-Filterd-Recvd-Size: 6622 Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Sun, 16 Feb 2020 20:38:46 +0000 (UTC) Received: from mail-qt1-f173.google.com ([209.85.160.173]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.145]) with ESMTPSA (Nemesis) id 1MRnTQ-1it0YQ2kW2-00TEl7 for ; Sun, 16 Feb 2020 21:38:44 +0100 Received: by mail-qt1-f173.google.com with SMTP id d9so10691892qte.12 for ; Sun, 16 Feb 2020 12:38:44 -0800 (PST) X-Gm-Message-State: APjAAAU+7wQbJK8g0Hh8kSB2m/ognI0XlnJjVJj6sToj1xbHFYjPXSIA HkzphOoMENVmdpGVhfHdqDka1+jDn4zTWKbjNM4= X-Google-Smtp-Source: APXvYqzGbYZ4aYpEY0TUWZN5AxiKnI5sM7fs3pGtoCEgh1lCGT2r9R0o04dDMj4EezabIIFY8gGD+8mZfxHFiF3300Y= X-Received: by 2002:ac8:3a27:: with SMTP id w36mr10771015qte.204.1581885523228; Sun, 16 Feb 2020 12:38:43 -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> In-Reply-To: From: Arnd Bergmann Date: Sun, 16 Feb 2020 21:38:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Chris Paterson Cc: Geert Uytterhoeven , 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 , "cip-dev@lists.cip-project.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:7MTvRrSyXPmp3eTtmFv7hsMevcUqFr1ff9qUgcDB2+H0Ta/xlaS sV0tgzJgRFZdUxZTcv1SQYbaxG73FoyiyKvzFKyeHT07REOm18GMXzcK0xuTCuXzg68ksz6 6TWnOdiSvw9l3tQN7QUiZ79GWOQkmqN5wr2Ky4pNMEBle2GDGDukZ3Ug7iXroAmbLkMsDdY 2VAe6vBK/YV7gmXDPSchA== X-UI-Out-Filterresults: notjunk:1;V03:K0:isFdG/OUOJs=:7zzfSqo904yzWsQcOiLQNE 1wjgN/pvuk6wbG8gH0mrQCjfmeeOgOUpiXqBaK9dDe4Ncy/s9MTQA/EmWGbZKgSpHQ4RT3oCu RbU8PkgT7H93kNAM/FbS1DYWHcAJj8aV2ormXCuytiARXx1LanoTCpecKjO5gd6FjTsmXYsZr qPCmH9gNOcYOChDoqgG7Ty+JKcweM3hADyUTkrqFM/2v5BG7KKXKB6a5ZSblK5CKtLuaQ2B8e XYGq2xniFjKpMkLEMLTBm1svxFQb4LUmnGwPVSHBkn8D7Yb9SN4t1A1ZNjje8i32Xq/RaZweS hNBQx0x3yzR50k7yxyY/MoDKlvomUQOtbL4FKuEkc73SfX1juU2KU/4y0g5P/GmT0O8/GFBgp N1x+maMXlhQ00Bci17V+N7hNlsm/AgIrRD1263aCjyHkhqwE8VSfphLY+EcHnUdR0iF9n/qXl x1AC7rhWdNlg6WeU9Ax40Cnl9/aEWY+EH+jLwW0TnDzR+dyoQrGH95QDsFX54es0mH/GYehdz R3tt3RAzIziz7sYmzWmjEq1owN+UN1X7UEam9Y7qnuiiQlAGvfwFKbOPFUOATXy7RsFMcFnx1 AYnfNZlZf7NQdusBUVKai4/oi3fWP/OSv+6zeJN94V8v/j8LASPIm47K6YLxfUTYfJqNQH/C/ taws44Umb36xJv73M46tKIYK7L+ZIZR8pOP+c761BI2IEnL5AWrQHVRW3YLV3VPjP41YjvAtB Qus+qV1lYxdDdp988kx5AA7pK5n4NQ0nSY4tp3wknSThuroxHiJxR9YgIHqLlUMwsRV+xY4ah c9lLHSi+d2EDh4QjDnu6KFg2PzG2GZ7NrGSVW6bZCbP/MX8GvM= 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 Sun, Feb 16, 2020 at 8:54 PM Chris Paterson wrote: > > Hello Arnd, Geert, > > > From: Geert Uytterhoeven > > Sent: 16 February 2020 09:45 > > To: Arnd Bergmann > > > > Hi Arnd, > > > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann wrote: > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven > > > wrote: > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann > > wrote: > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > > > > wrote: > > > > > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one above > > > > the 32-bit physical limit. > > Yep. One example is r8a7743-iwg20m.dtsi. This one has 2x512MB, with half above the 4GiB limit. This means it needs LPAE to address high physical addresses (which is fine), but it does not need highmem if one uses an appropriate CONFIG_VMSPLIT_* option. > > > Good to know. I think there are several other chips that have dual-channel > > > DDR3 and thus /can/ support this configuration, but this rarely happens. > > > Are you aware of commercial products that use a 4GB configuration, aside > > from > > > the reference board? > > iWave Systems make a range of SOM modules using the RZ/G1 SoCs. > I believe there are options for some of these to use 4 GB, although 1 or 2 GB is > used in the boards we've upstreamed support for. > > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1, > but I'm not sure of the details. Both iWave and Emtrion only seem to list boards with 2GB or less on their websites today (with up to 15 year availability). My guess is that they had the same problem as everyone else in finding the right memory chips in the required quantities and/or long-term availability. iWave lists "By default 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory expansion support." on some boards, but that doesn't mean they ever shipped a 4GB configuration. 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 8B0A3C76199 for ; Sun, 16 Feb 2020 20:39:07 +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 544A620729 for ; Sun, 16 Feb 2020 20:39:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="mGgxXX9x" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 544A620729 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=wwwYvwvmH+nVlJYVAj7uyaZY8+FpmaeCD0vThn2R/zI=; b=mGgxXX9x35l2oT XgItpauCku26UJ3A2YrYM8uoSCTOGil4zuc6OQrK2fCbrY7No/oTmcCSIvG+Ki/ePM5+QYYPM/9pc nqf+YKXFkFlOFOfxf4BOKhuMZ/NkGDuhSubtAFybpgAz5XAhmmvz0yPHBWcOmyHiu+50zJY5px7t9 ax9hYuELaCG0Ou+Rx56WfEw0/CxqfgzE3UFkIi6cZuGiD6yA565Pfk+iO8M5wJXcbxhiEkM9toPxs V5h8NLcv163VpgYOoM5xTrTL84WcQw8cwB7ZR5iO2h8c+/UbaW5lWRE8C4q9C0NfPCrvEatL2P/8+ eo/q2jq2OgU0+tcwoY7Q==; 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 1j3Qgo-0004JV-8i; Sun, 16 Feb 2020 20:38:54 +0000 Received: from mout.kundenserver.de ([217.72.192.73]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1j3Qgk-0004IW-Mf for linux-arm-kernel@lists.infradead.org; Sun, 16 Feb 2020 20:38:52 +0000 Received: from mail-qt1-f181.google.com ([209.85.160.181]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mate1-1jaYmc2GDr-00cQIg for ; Sun, 16 Feb 2020 21:38:45 +0100 Received: by mail-qt1-f181.google.com with SMTP id c5so10712833qtj.6 for ; Sun, 16 Feb 2020 12:38:44 -0800 (PST) X-Gm-Message-State: APjAAAW+pSk7lhH+T2f3It7MPqg0DKGwYrJ0ZSpRfshxN9dQlR8jE+gF vrxu55uskCbULWaaPedjfAUk5CRy9H4Kbe/gexY= X-Google-Smtp-Source: APXvYqzGbYZ4aYpEY0TUWZN5AxiKnI5sM7fs3pGtoCEgh1lCGT2r9R0o04dDMj4EezabIIFY8gGD+8mZfxHFiF3300Y= X-Received: by 2002:ac8:3a27:: with SMTP id w36mr10771015qte.204.1581885523228; Sun, 16 Feb 2020 12:38:43 -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> In-Reply-To: From: Arnd Bergmann Date: Sun, 16 Feb 2020 21:38:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU To: Chris Paterson X-Provags-ID: V03:K1:65Vh3rzOfExv9DA7mFA85XNYseEAGoZq5gc3yhFZrqZBX1Gw/Nr PEjnC4kklTTjWTzfopxoNticHW1iLriI1/gE/1IqJ3swXIa2P5CAc1KcTwBOhWOa3DvrBJs 3plSUxNm5eTXsmcWYpVp89EZkh3vQALSPpN5cYZCBogMrQdpDrgYtMHlZd0mh2mvbrZSEnp ij8PavvWbBjYejCduBlDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:BfBSQreGKw0=:Wsfezhhe8AXR6C4m3ZFrI/ /fOvvZrpUpGBcyeAN/GIx9PmnuAjn2b7yrsptcOTLpU8AYfpbydH2zf/eHWQGOKLou6UGAJGJ N421VyhAMUQEnWpgYjwEk8UGrxH8ExOQEwiaTaeJ8NZD2slW+jvXp49UgU5aeQgOz1eOOxDA1 J/eeM0O5SJIqhyYhWOoS7NEAHfBY2zoK1RHa6HgN3kHxvh0vtbi6XXaq0JsnkkD15ciBmNjPq 30GTG7AHIJINIBWSsUCvQVvJT2KfkeQI9qFXEQlwny88S5Rd0cjLMWmgrs122JFtoCEtDVbia 5HVNVd+eiG0fKxaGDSOxBhoR6jIfQex+R3Fl7ykJh10lxGVG7rVnuYF1Em+WO6Ac31lAWZ3FK sRM1OWNhziu4fyKfTtkS5PYDvrSz8oH9UW0sQjVpne0farMab5TITfWMZGGpVfwk5iKxllBYM 8mY9SbOSO9P9XSzGsTwqjzO2YIy1P9n15PwKrghX3H+8YiPeSHg3S0ePezAYvfeVSvX2PowX1 6inMGgrNK9mXIgpr5n53uZ+j9YTPagVsDjCAV6nK7BxTXDbltK5amALQQVrV+kBgBih/XUdaO 3MTNAVvoWHev6WA/LxnFxRacPYsaYumig3XmcQJQix8oOMsksHicaEzXsRr8Eix9QD9BeTaPF 8/iBEV5yNQcRuxCajFD1z5lFLTVdTSUbRhK52+KqREzxWvTInypHjRtBctrEHUojM55OMcTbj CW+0jYXnORFNRPJEbzPylIJGNj5+ttnBxA4jUgflNVpz0NpNv+0jxjK9LhkiSx9arEi/e0YuS 0zUY7ZtsxYCNxWLHyLK+ZCHxc8/1nYkBpu/f6v1EbrTNXvz7og= X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200216_123851_039284_C4767FD5 X-CRM114-Status: GOOD ( 21.95 ) 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 , Geert Uytterhoeven , Al Viro , "cip-dev@lists.cip-project.org" , 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 Sun, Feb 16, 2020 at 8:54 PM Chris Paterson wrote: > > Hello Arnd, Geert, > > > From: Geert Uytterhoeven > > Sent: 16 February 2020 09:45 > > To: Arnd Bergmann > > > > Hi Arnd, > > > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann wrote: > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven > > > wrote: > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann > > wrote: > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > > > > wrote: > > > > > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one above > > > > the 32-bit physical limit. > > Yep. One example is r8a7743-iwg20m.dtsi. This one has 2x512MB, with half above the 4GiB limit. This means it needs LPAE to address high physical addresses (which is fine), but it does not need highmem if one uses an appropriate CONFIG_VMSPLIT_* option. > > > Good to know. I think there are several other chips that have dual-channel > > > DDR3 and thus /can/ support this configuration, but this rarely happens. > > > Are you aware of commercial products that use a 4GB configuration, aside > > from > > > the reference board? > > iWave Systems make a range of SOM modules using the RZ/G1 SoCs. > I believe there are options for some of these to use 4 GB, although 1 or 2 GB is > used in the boards we've upstreamed support for. > > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1, > but I'm not sure of the details. Both iWave and Emtrion only seem to list boards with 2GB or less on their websites today (with up to 15 year availability). My guess is that they had the same problem as everyone else in finding the right memory chips in the required quantities and/or long-term availability. iWave lists "By default 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory expansion support." on some boards, but that doesn't mean they ever shipped a 4GB configuration. Arnd _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Sun, 16 Feb 2020 21:38:27 +0100 Subject: [cip-dev] [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU In-Reply-To: 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> Message-ID: To: cip-dev@lists.cip-project.org List-Id: cip-dev.lists.cip-project.org On Sun, Feb 16, 2020 at 8:54 PM Chris Paterson wrote: > > Hello Arnd, Geert, > > > From: Geert Uytterhoeven > > Sent: 16 February 2020 09:45 > > To: Arnd Bergmann > > > > Hi Arnd, > > > > On Sat, Feb 15, 2020 at 5:59 PM Arnd Bergmann wrote: > > > On Sat, Feb 15, 2020 at 12:25 PM Geert Uytterhoeven > > > wrote: > > > > On Thu, Feb 13, 2020 at 5:54 PM Arnd Bergmann > > wrote: > > > > > On Wed, Feb 12, 2020 at 9:50 AM Russell King - ARM Linux admin > > > > > wrote: > > > > > > > > The CIP-supported RZ/G1 SoCs can have up to 4 GiB, typically split (even > > > > for 1 GiB or 2 GiB configurations) in two parts, one below and one above > > > > the 32-bit physical limit. > > Yep. One example is r8a7743-iwg20m.dtsi. This one has 2x512MB, with half above the 4GiB limit. This means it needs LPAE to address high physical addresses (which is fine), but it does not need highmem if one uses an appropriate CONFIG_VMSPLIT_* option. > > > Good to know. I think there are several other chips that have dual-channel > > > DDR3 and thus /can/ support this configuration, but this rarely happens. > > > Are you aware of commercial products that use a 4GB configuration, aside > > from > > > the reference board? > > iWave Systems make a range of SOM modules using the RZ/G1 SoCs. > I believe there are options for some of these to use 4 GB, although 1 or 2 GB is > used in the boards we've upstreamed support for. > > There are also other SOM vendors (e.g. Emtrion) and end users of RZ/G1, > but I'm not sure of the details. Both iWave and Emtrion only seem to list boards with 2GB or less on their websites today (with up to 15 year availability). My guess is that they had the same problem as everyone else in finding the right memory chips in the required quantities and/or long-term availability. iWave lists "By default 1GB DDR3 and 4GB eMMC only supported. Contact iWave for memory expansion support." on some boards, but that doesn't mean they ever shipped a 4GB configuration. Arnd