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 92BF1C43334 for ; Tue, 7 Jun 2022 08:39:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 10D5F6B0072; Tue, 7 Jun 2022 04:39:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0BD046B0073; Tue, 7 Jun 2022 04:39:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F15C96B0074; Tue, 7 Jun 2022 04:39:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id E0E516B0072 for ; Tue, 7 Jun 2022 04:39:15 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B56F220577 for ; Tue, 7 Jun 2022 08:39:15 +0000 (UTC) X-FDA: 79550790270.05.81F592A Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) by imf11.hostedemail.com (Postfix) with ESMTP id 9DCEB40003 for ; Tue, 7 Jun 2022 08:39:05 +0000 (UTC) Received: from mail-yb1-f173.google.com ([209.85.219.173]) by mrelayeu.kundenserver.de (mreue106 [213.165.67.113]) with ESMTPSA (Nemesis) id 1N33ZD-1nmLhk0LRF-013OZN for ; Tue, 07 Jun 2022 10:39:13 +0200 Received: by mail-yb1-f173.google.com with SMTP id f34so29962176ybj.6 for ; Tue, 07 Jun 2022 01:39:12 -0700 (PDT) X-Gm-Message-State: AOAM530rtZcrq12/nLR2xstunFOWpYJnesfRLMc+JRbKknxrVG0Pxu0O LS/1WABtaB/AHIBLYy6fNXZ49Z7MmKPc31QgYo8= X-Google-Smtp-Source: ABdhPJzylI9I5JeBPjUUut8ayM+PvfwNZmiVMAF/BvUxDvvXJcaZCKQ3fgna4UMbv4431pCM1UUoaNu3EP7e+hK1CUE= X-Received: by 2002:a25:1209:0:b0:65d:63f9:e10a with SMTP id 9-20020a251209000000b0065d63f9e10amr28588322ybs.480.1654591151578; Tue, 07 Jun 2022 01:39:11 -0700 (PDT) MIME-Version: 1.0 References: <70b4e1e46d9d63275a0dfe90f96f40ea14d89f0c.camel@infinera.com> <88dfec5a1c98f4eb71e23cafe89db4395ea12811.camel@infinera.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 7 Jun 2022 10:38:54 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Finding kernel RAM consumers ? To: Arnd Bergmann , Matthew Wilcox , Joakim Tjernlund , "linux-mm@kvack.org" , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:2v5g4Ejb70nSrvg899ErjHyiH0hz/A0jVoU8oLxcSPh54jXjia/ LdSjrHpIljZSvwKz5zDlr3X7SFHdtihs9UC3hyx5A6xGwd051ja9fD1rUjpika/EtqOT3h+ pIS8V7I8ofh76LqqTuWdABfIlDLPWnRTmQXMKU/kZK9qmaSitjEoZ4ueTatHRc9l/cbVz7v LeaoJhXdUfUNFtIToW0gw== X-UI-Out-Filterresults: notjunk:1;V03:K0:qK1SrbEZJIM=:6jT/bYMzz7y+Z4e69xRUl6 SbKcRU/MdhCwUnk42FXNaeauyokM4Y3Y/HDtkBtgBU0LfUvV0tMWdeYJAW3+Pq0X5TB5E9SD4 sxnjkZ0dt4E/nJKWsfLt6fG0dK03Oli9G7EqKVwz+7QALq1E5TP/ZYdQtXMiBvCUYvMsjCxCH kEIDY70xuAM4ZRnh6Ff0b/d3BFEcXLyGNrvfDnYWPqTnPE1Q1AygOcqjz13yYsntdZx+Fy8rV oS9s2uZNY0x5hGUuZKoHbxzR3NZR7QU9Kl7eck6Vsbh3+kOthCGK+2sfXp6R/rgl6Ayd0rJZS q4gdNayez13vfHGmzEw65nbFwz0WWypx8q9R5FeiHyFmWvTpVE1iNamTVoPn6NT5hr4q8JBXQ 3oaJ2Z9nJSWjwl9RVeLYGc0AWEFDg854c1PDpIIVJ8mG4e362SJ1Mx/pUlM4LoPMs7dWkwj31 qqlYIfrC+WvJm0AR9SC1FFB5Al5owN6Wg1YAXcWCmKWCGdLjyxhrl2mq8ORDX38Dj/aP+K3+K L31mEVEOBxwqRjku+VyRZeAAi+9yY51SInwQzivQ33Swqs+KLpIQUrqxNo3QepK8pj04YS7S4 f1GS1E0QMRUvs1h2cLWmVddWXpOc7GbGP2+GuYbF9EoTDqy50phI8mGwW8CWQ5V4U+wERqPMY uXLIPXfSMuaSB7NFhevkxCzroDdM/FrmTsAjF+FZ3HBuDBgv8ytEY4Gdvulcib/79FqXOGXqz yEo2SlbuqRb8uH5Pc/Vd6DJ/+UUwpuj8lmxhNQ== Authentication-Results: imf11.hostedemail.com; dkim=none; spf=none (imf11.hostedemail.com: domain of arnd@arndb.de has no SPF policy when checking 217.72.192.75) smtp.mailfrom=arnd@arndb.de; dmarc=none X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 9DCEB40003 X-Rspam-User: X-Stat-Signature: c9wstyn17ociqfnwfmy5a1s4bj7xt97r X-HE-Tag: 1654591145-629900 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 Tue, Jun 7, 2022 at 7:41 AM Alexander Dahl wrote: > Am Fri, Jun 03, 2022 at 08:11:31PM +0200 schrieb Arnd Bergmann: > > On Fri, Jun 3, 2022 at 7:29 PM Matthew Wilcox wrote: > > > > I think this is a case of "patches welcome". Nobody has really needed > > this so far, but as even the smaller machines are slowly migrating from > > 32-bit to 64-bit cores, optimizing this will get interesting for more > > developers. There are probably other low-hanging > > fruit that you can address after figuring out. > > The SiP variants of at91 SAMA5D2 (armv7) or SAM9x60 (armv5) come with > 64 MiB or 128 MiB, and given the latter is a new SoC announced only > two or three years ago, requiring at least 256 MiB would be at best > unfortunate. Given those SoCs are used in industrial applications > with very long support times, I think 32bit ARM will stay for years, > even with new products. Yes, of course, and there is nothing wrong with that. We already see Cortex-A7 cores down to 7nm, all running Linux, and I expect there will likely be another 5 to 10 years of new 32-bit chips, and then another 10 years of people putting the existing chips into production, and after that a slow decline of users updating their kernels before supporting 32-bit hardware becomes too expensive to support in the kernel. On hardware that can run both 32-bit and 64-bit kernels, there are pretty much only upsides to running 64-bit kernels (with 32-bit thumb user space), but there is a memory overhead for the kernel itself, usually some 20 to 30 MB. Reducing this difference can hopefully help get fewer users stuck on 32-bit kernels by the time that they get too painful to use. > > One observation I made is that modern kernels don't seem to deal as > > well as older ones with low-memory situations, so even if you manage > > to free up most of your 32MB, it might still not work reliably. > > Since we are using the SAMA5D27C-D5M in production, I would also be > interested in support for running 32 bit ARM with recent kernels on > systems with 64 MiB or even 32 MiB of memory. If there are specific > things to test, you can let me know. I don't have anything specific, just the general feeling that there is something wrong about memory reclaim in smaller configurations. A system that is fine after bootup can run for a long time without running out of memory, but one thing I've observed in the past is that after a process manages to consume all RAM and swap space, killing that one task does not restore the overall system back into the same state as before, and it remains sluggish. Another issue is that I think we have more broken error handling for failed in-kernel memory allocations. After you see the kernel fail an allocation, I would usually recommend a reboot, and my feeling is that this used to be better in the past. Both of these could of course just be side-effects of kernel bloat, where a particular workload is now worse than in the past because it now needs more RAM to do the same thing. Arnd