linux-kernel - Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 8 Mar 2020 11:58:52 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nishanth Menon <nm@...com>
Cc:     Santosh Shilimkar <santosh.shilimkar@...cle.com>,
        Tero Kristo <t-kristo@...com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Michal Hocko <mhocko@...e.com>,
        Rik van Riel <riel@...riel.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Dave Chinner <david@...morbit.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>,
        Yafang Shao <laoar.shao@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Johannes Weiner <hannes@...xchg.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        kernel-team@...com, Kishon Vijay Abraham I <kishon@...com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Roman Gushchin <guro@...com>
Subject: Re: [PATCH] vfs: keep inodes with page cache off the inode shrinker LRU

On Fri, Mar 6, 2020 at 9:36 PM Nishanth Menon <nm@...com> wrote:
> On 13:11-20200226, santosh.shilimkar@...cle.com wrote:

>
> ~few 1000s still relevant spread between 4G and 8G (confirmed that both
> are present, relevant and in use).
>
> I wish we could sunset, but unfortunately, I am told(and agree)
> that we should'nt just leave products (and these are long term
> products stuck in critical parts in our world) hanging in the air, and
> migrations to newer kernel do still take place periodically (the best
> I can talk in public forum at least).

Thank you for the clear answer!

I agree we should certainly not break any such use cases, and for the
8GB case there is not really a good replacement (using zram/zswap
instead of highmem could work for some new workloads, but would be a
rather risky change for an upgrade on already deployed systems).

I hope it's ok to ask the same question every few years until you are
reasonably sure that the users are ready to stop upgrading kernels
beyond the following LTS kernel version. We can also do the same
thing for the other 32-bit platforms that exceed the maximum amount
of lowmem, and document which ones are known.

In the meantime, it would seem useful to increase the amount of
lowmem that can be used by default, using a combination of some
of the changes mentioned earlier

- add a VMSPLIT_2G_OPT config option for non-LPAE ARM kernels
  to handle the common i.MX6 case with 2GB of RAM without highmem

- make VMSPLIT_2G_OPT (without LPAE) or VMSPLIT_2G (with
  LPAE) the default in most ARM defconfig files as well as distros,
  and disable highmem where possible, to see what breaks.

- extend zswap to use all the available high memory for swap space
  when highmem is disabled.

- revisit CONFIG_VMSPLIT_4G_4G for arm32 (and maybe mips32)
  to see if it can be done, and what the overhead is. This is probably
  more work than the others combined, but also the most promising
  as it allows the most user address space and physical ram to be used.

       Arnd