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