From: Arnd Bergmann <arnd@arndb.de>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>,
Matthew Wilcox <willy@infradead.org>,
Joakim Tjernlund <Joakim.Tjernlund@infinera.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Finding kernel RAM consumers ?
Date: Tue, 7 Jun 2022 12:22:53 +0200 [thread overview]
Message-ID: <CAK8P3a0p=nJH3SiE=XBx3AjhPkWzq7gMZmCrb-3+ZqQmOwp0wg@mail.gmail.com> (raw)
In-Reply-To: <Yp8d7NZ561/yr0HF@shell.armlinux.org.uk>
On Tue, Jun 7, 2022 at 11:44 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
> On Tue, Jun 07, 2022 at 10:38:54AM +0200, Arnd Bergmann wrote:
> >
> > 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.
>
> It should be noted that 20 years puts us past the 2038 32-bit time_t
> wrap problem - and although there's been work to address that in the
> UAPI, that doesn't mean that userspace will cope.
>
> Anyone deploying a system that is expected to still be live beyond
> the end of 32-bit time_t had better be testing their userspace for
> that event now!
That is absolutely true, but it's also independent of what kernel is
being used. I assume that anyone who is this memory constrained
is using 32-bit thumb userspace even on 64-bit kernels.
The base distro support in embedded systems using openembedded
with musl-1.2.x usually works fine beyond y2038, but of course each
system should be tested for this before shipping as there are still
bugs in less common code.
arnd
prev parent reply other threads:[~2022-06-07 10:23 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 19:24 Joakim Tjernlund
2022-06-02 20:11 ` Matthew Wilcox
2022-06-03 6:49 ` Joakim Tjernlund
2022-06-03 17:26 ` Joakim Tjernlund
2022-06-03 17:29 ` Matthew Wilcox
2022-06-03 18:11 ` Arnd Bergmann
2022-06-07 5:41 ` Alexander Dahl
2022-06-07 8:38 ` Arnd Bergmann
2022-06-07 8:54 ` Joakim Tjernlund
[not found] ` <Yp8d7NZ561/yr0HF@shell.armlinux.org.uk>
2022-06-07 10:22 ` Arnd Bergmann [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK8P3a0p=nJH3SiE=XBx3AjhPkWzq7gMZmCrb-3+ZqQmOwp0wg@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=Joakim.Tjernlund@infinera.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux@armlinux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox