From: Arnd Bergmann <arnd@kernel.org> To: Max Filippov <jcmvbkbc@gmail.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, Linus Walleij <linus.walleij@linaro.org>, Gerhard Pircher <gerhard_pircher@gmx.net>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, Sparc kernel list <sparclinux@vger.kernel.org>, Linux-sh list <linux-sh@vger.kernel.org> Subject: Re: Old platforms: bring out your dead Date: Fri, 15 Jan 2021 09:31:53 +0100 [thread overview] Message-ID: <CAK8P3a16dta82GOVZCcMgFokB4Mo6y6Vje=+5gUH-t-1ATQYUw@mail.gmail.com> (raw) In-Reply-To: <CAMo8Bf+geJqaaTkwaRyMUZPJgGC1ELXTdnYGq92UNnaaz2CFVg@mail.gmail.com> On Fri, Jan 15, 2021 at 12:09 AM Max Filippov <jcmvbkbc@gmail.com> wrote: > On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <arnd@kernel.org> wrote: > > | arch/mips/Kconfig:config HIGHMEM > > | arch/xtensa/Kconfig:config HIGHMEM > > > > AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at > > most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G > > tricks won't work. > > Regarding xtensa this was done to minimize difference between > MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been > obsoleted more than 10 years ago, and MMUv3 is much more > flexible and can do e.g. 4GB linear map. The only piece of xtensa > MMUv2 hardware that I have has 96MB of DRAM which fits into > its linear mapping. So maybe it's time to do a cleanup and > rearrange virtual memory layout to eliminate the need of highmem. Yes, I think that sounds like a useful preparation for the future. > > I have no idea who uses xtensa systems with lots of memory on > > modern kernels. > > We definitely use it for development internally at Cadence/Tensilica, > mainly on simulators, but also on FPGA boards (e.g. on KC705 we > can use all of the 1GB onboard DRAM). > In the last few years we've had a few support requests for linux on > xtensa cores with MMU, but AFAICT none of them had to deal with > more than 512MB of onboard memory. If 1GB of RAM is a useful upper bound on MMUv3, the easiest way is probably to hardcode the CONFIG_VMSPLIT_3G_OPT behavior from x86 and ARM, using 2.75GB of user addresses (TASK_SIZE), and 1.25 GB that gets split between linear map and vmalloc space, but no uncached linear map and ioremap() pointing into vmalloc instead. If you want to be prepared for machines with 2GB of linear lowmem, you could do the same with VMSPLIT_2G_OPT (TASK_SIZE == 0x70000000). Arnd
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@kernel.org> To: Max Filippov <jcmvbkbc@gmail.com> Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>, Linus Walleij <linus.walleij@linaro.org>, Gerhard Pircher <gerhard_pircher@gmx.net>, Arnd Bergmann <arnd@arndb.de>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, linux-m68k <linux-m68k@lists.linux-m68k.org>, Sparc kernel list <sparclinux@vger.kernel.org>, Linux-sh list <linux-sh@vger.kernel.org> Subject: Re: Old platforms: bring out your dead Date: Fri, 15 Jan 2021 08:31:53 +0000 [thread overview] Message-ID: <CAK8P3a16dta82GOVZCcMgFokB4Mo6y6Vje=+5gUH-t-1ATQYUw@mail.gmail.com> (raw) In-Reply-To: <CAMo8Bf+geJqaaTkwaRyMUZPJgGC1ELXTdnYGq92UNnaaz2CFVg@mail.gmail.com> On Fri, Jan 15, 2021 at 12:09 AM Max Filippov <jcmvbkbc@gmail.com> wrote: > On Thu, Jan 14, 2021 at 1:25 PM Arnd Bergmann <arnd@kernel.org> wrote: > > | arch/mips/Kconfig:config HIGHMEM > > | arch/xtensa/Kconfig:config HIGHMEM > > > > AFAICT On MIPS (prior to MIPS32r3) and xtensa, you have at > > most 512MB in the linear map, so the VMSPLIT_2G or VMSPLIT_4G_4G > > tricks won't work. > > Regarding xtensa this was done to minimize difference between > MMUv2 and MMUv3 virtual memory layouts. MMUv2 has been > obsoleted more than 10 years ago, and MMUv3 is much more > flexible and can do e.g. 4GB linear map. The only piece of xtensa > MMUv2 hardware that I have has 96MB of DRAM which fits into > its linear mapping. So maybe it's time to do a cleanup and > rearrange virtual memory layout to eliminate the need of highmem. Yes, I think that sounds like a useful preparation for the future. > > I have no idea who uses xtensa systems with lots of memory on > > modern kernels. > > We definitely use it for development internally at Cadence/Tensilica, > mainly on simulators, but also on FPGA boards (e.g. on KC705 we > can use all of the 1GB onboard DRAM). > In the last few years we've had a few support requests for linux on > xtensa cores with MMU, but AFAICT none of them had to deal with > more than 512MB of onboard memory. If 1GB of RAM is a useful upper bound on MMUv3, the easiest way is probably to hardcode the CONFIG_VMSPLIT_3G_OPT behavior from x86 and ARM, using 2.75GB of user addresses (TASK_SIZE), and 1.25 GB that gets split between linear map and vmalloc space, but no uncached linear map and ioremap() pointing into vmalloc instead. If you want to be prepared for machines with 2GB of linear lowmem, you could do the same with VMSPLIT_2G_OPT (TASK_SIZE = 0x70000000). Arnd
next prev parent reply other threads:[~2021-01-15 8:32 UTC|newest] Thread overview: 246+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-08 22:55 Old platforms: bring out your dead Arnd Bergmann 2021-01-08 22:55 ` Arnd Bergmann 2021-01-08 23:32 ` Steven Rostedt 2021-01-08 23:32 ` Steven Rostedt 2021-01-09 22:04 ` Arnd Bergmann 2021-01-09 22:04 ` Arnd Bergmann 2021-01-08 23:44 ` Thomas Bogendoerfer 2021-01-08 23:44 ` Thomas Bogendoerfer 2021-01-09 0:16 ` Linus Walleij 2021-01-09 0:16 ` Linus Walleij 2021-01-09 17:32 ` Florian Fainelli 2021-01-09 17:32 ` Florian Fainelli 2021-01-09 21:59 ` Arnd Bergmann 2021-01-09 21:59 ` Arnd Bergmann 2021-01-09 5:56 ` Willy Tarreau 2021-01-09 5:56 ` Willy Tarreau 2021-01-09 21:52 ` Arnd Bergmann 2021-01-09 21:52 ` Arnd Bergmann 2021-01-10 6:21 ` Willy Tarreau 2021-01-10 6:21 ` Willy Tarreau 2021-01-10 10:44 ` Russell King - ARM Linux admin 2021-01-10 10:44 ` Russell King - ARM Linux admin 2021-01-11 9:50 ` David Laight 2021-01-11 9:50 ` David Laight 2021-01-13 10:27 ` Andy Shevchenko 2021-01-13 10:27 ` Andy Shevchenko 2021-01-13 12:02 ` Linus Walleij 2021-01-13 12:02 ` Linus Walleij 2021-01-13 12:17 ` Andy Shevchenko 2021-01-13 12:17 ` Andy Shevchenko 2021-01-13 12:21 ` Andy Shevchenko 2021-01-13 12:21 ` Andy Shevchenko 2021-01-15 0:03 ` Bernd Petrovitsch 2021-01-15 0:03 ` Bernd Petrovitsch 2021-01-15 0:24 ` William Breathitt Gray 2021-01-15 0:24 ` William Breathitt Gray 2021-01-15 8:59 ` David Laight 2021-01-15 8:59 ` David Laight 2021-01-13 12:30 ` William Breathitt Gray 2021-01-13 12:30 ` William Breathitt Gray 2021-01-13 12:56 ` William Breathitt Gray 2021-01-13 12:56 ` William Breathitt Gray 2021-01-13 13:44 ` Arnd Bergmann 2021-01-13 13:44 ` Arnd Bergmann 2021-02-04 21:01 ` Pavel Machek 2021-02-04 21:01 ` Pavel Machek 2021-02-05 9:13 ` David Laight 2021-02-05 9:13 ` David Laight 2021-02-05 9:29 ` Pavel Machek 2021-02-05 9:29 ` Pavel Machek 2021-01-09 17:34 ` Florian Fainelli 2021-01-09 17:34 ` Florian Fainelli 2021-01-09 21:18 ` Arnd Bergmann 2021-01-09 21:18 ` Arnd Bergmann 2021-01-09 17:43 ` Russell King - ARM Linux admin 2021-01-09 17:43 ` Russell King - ARM Linux admin 2021-01-09 21:34 ` Arnd Bergmann 2021-01-09 21:34 ` Arnd Bergmann 2021-01-11 20:09 ` Russell King - ARM Linux admin 2021-01-11 20:09 ` Russell King - ARM Linux admin 2021-01-09 20:19 ` Baruch Siach 2021-01-09 20:19 ` Baruch Siach 2021-01-09 21:19 ` Arnd Bergmann 2021-01-09 21:19 ` Arnd Bergmann [not found] ` <67171E13-6786-4B44-A8C2-3302963B055F@gmail.com> 2021-01-09 22:20 ` Arnd Bergmann 2021-01-09 22:20 ` Arnd Bergmann 2021-01-10 18:12 ` Fabian Vogt 2021-01-10 18:12 ` Fabian Vogt 2021-01-10 19:20 ` Arnd Bergmann 2021-01-10 19:20 ` Arnd Bergmann 2021-01-10 21:33 ` Linus Walleij 2021-01-10 21:33 ` Linus Walleij 2021-01-11 0:33 ` Russell King - ARM Linux admin 2021-01-11 0:33 ` Russell King - ARM Linux admin 2021-01-11 12:32 ` Arnd Bergmann 2021-01-11 12:32 ` Arnd Bergmann 2021-01-11 12:36 ` Russell King - ARM Linux admin 2021-01-11 12:36 ` Russell King - ARM Linux admin 2021-01-09 23:12 ` Andrew Lunn 2021-01-09 23:12 ` Andrew Lunn 2021-01-10 8:45 ` Arnd Bergmann 2021-01-10 8:45 ` Arnd Bergmann 2021-01-10 16:46 ` Andrew Lunn 2021-01-10 16:46 ` Andrew Lunn 2021-01-10 17:27 ` Arnd Bergmann 2021-01-10 17:27 ` Arnd Bergmann 2021-01-10 19:51 ` Andrew Lunn 2021-01-10 19:51 ` Andrew Lunn 2021-01-10 15:51 ` Neil Armstrong 2021-01-10 15:51 ` Neil Armstrong 2021-01-10 15:56 ` Arnd Bergmann 2021-01-10 15:56 ` Arnd Bergmann 2021-01-10 17:35 ` John Paul Adrian Glaubitz 2021-01-10 17:35 ` John Paul Adrian Glaubitz 2021-01-10 21:46 ` Sam Ravnborg 2021-01-10 21:46 ` Sam Ravnborg 2021-01-11 8:05 ` John Paul Adrian Glaubitz 2021-01-11 8:05 ` John Paul Adrian Glaubitz 2021-01-11 14:55 ` chase rayfield 2021-01-11 14:55 ` chase rayfield 2021-01-12 0:26 ` Rob Landley 2021-01-12 0:26 ` Rob Landley 2021-01-12 0:50 ` chase rayfield 2021-01-12 0:50 ` chase rayfield 2021-01-12 14:37 ` John Paul Adrian Glaubitz 2021-01-12 14:37 ` John Paul Adrian Glaubitz 2021-01-11 17:57 ` Rob Landley 2021-01-11 18:09 ` Rob Landley 2021-01-11 15:04 ` Gerhard Pircher 2021-01-11 15:04 ` Gerhard Pircher 2021-01-12 14:44 ` John Paul Adrian Glaubitz 2021-01-12 14:44 ` John Paul Adrian Glaubitz 2021-01-12 22:46 ` Linus Walleij 2021-01-12 22:46 ` Linus Walleij 2021-01-13 7:57 ` Rob Landley 2021-01-13 8:09 ` Rob Landley 2021-01-13 8:21 ` Geert Uytterhoeven 2021-01-13 8:21 ` Geert Uytterhoeven 2021-01-13 13:25 ` Rob Landley 2021-01-13 13:25 ` Rob Landley 2021-01-13 12:02 ` Andy Shevchenko 2021-01-13 12:02 ` Andy Shevchenko 2021-01-13 8:15 ` Geert Uytterhoeven 2021-01-13 8:15 ` Geert Uytterhoeven 2021-01-13 10:39 ` Arnd Bergmann 2021-01-13 10:39 ` Arnd Bergmann 2021-01-14 3:54 ` New platforms: bring out your dead, was " Finn Thain 2021-01-14 3:54 ` Finn Thain 2021-01-14 9:41 ` John Paul Adrian Glaubitz 2021-01-14 9:41 ` John Paul Adrian Glaubitz 2021-01-14 9:48 ` Geert Uytterhoeven 2021-01-14 9:48 ` Geert Uytterhoeven 2021-01-14 21:21 ` Arnd Bergmann 2021-01-14 21:21 ` Arnd Bergmann 2021-01-14 22:54 ` Undesirable code, was Re: Old platforms etc Finn Thain 2021-01-14 22:54 ` Finn Thain 2021-01-14 23:09 ` Old platforms: bring out your dead Max Filippov 2021-01-14 23:09 ` Max Filippov 2021-01-15 8:31 ` Arnd Bergmann [this message] 2021-01-15 8:31 ` Arnd Bergmann 2021-01-13 0:12 ` Old platforms never die, was " Finn Thain 2021-01-13 0:12 ` Finn Thain 2021-01-16 6:54 ` Rob Landley 2021-01-16 6:54 ` Rob Landley 2021-01-16 23:22 ` Finn Thain 2021-01-16 23:22 ` Finn Thain 2021-01-13 11:47 ` Andy Shevchenko 2021-01-13 11:47 ` Andy Shevchenko 2021-01-11 1:39 ` Daniel Palmer 2021-01-11 1:39 ` Daniel Palmer 2021-01-11 9:15 ` John Paul Adrian Glaubitz 2021-01-11 9:15 ` John Paul Adrian Glaubitz 2021-01-11 9:20 ` Geert Uytterhoeven 2021-01-11 9:20 ` Geert Uytterhoeven 2021-01-11 9:26 ` John Paul Adrian Glaubitz 2021-01-11 9:26 ` John Paul Adrian Glaubitz 2021-01-11 9:36 ` Geert Uytterhoeven 2021-01-11 9:36 ` Geert Uytterhoeven 2021-01-11 9:50 ` Greg Ungerer 2021-01-11 9:50 ` Greg Ungerer 2021-01-11 9:42 ` Daniel Palmer 2021-01-11 9:42 ` Daniel Palmer 2021-01-11 10:13 ` Arnd Bergmann 2021-01-11 10:13 ` Arnd Bergmann 2021-01-11 8:19 ` Geert Uytterhoeven 2021-01-11 8:19 ` Geert Uytterhoeven 2021-01-11 8:59 ` Arnd Bergmann 2021-01-11 8:59 ` Arnd Bergmann 2021-01-11 9:16 ` Geert Uytterhoeven 2021-01-11 9:16 ` Geert Uytterhoeven 2021-01-11 10:28 ` Geert Uytterhoeven 2021-01-11 10:28 ` Geert Uytterhoeven 2021-01-11 10:37 ` Arnd Bergmann 2021-01-11 10:37 ` Arnd Bergmann 2021-01-11 9:40 ` Thomas Bogendoerfer 2021-01-11 9:40 ` Thomas Bogendoerfer 2021-01-11 10:34 ` Arnd Bergmann 2021-01-11 10:34 ` Arnd Bergmann 2021-01-11 8:40 ` efm32 is dead [Was: Old platforms: bring out your dead] Uwe Kleine-König 2021-01-11 8:49 ` Old platforms: bring out your dead Alexander Sverdlin 2021-01-11 9:31 ` Arnd Bergmann 2021-01-11 10:27 ` Alexander Sverdlin 2021-01-11 11:00 ` Arnd Bergmann 2021-01-11 8:53 ` Alexander Sverdlin 2021-01-11 11:10 ` Viresh Kumar 2021-01-11 11:10 ` Viresh Kumar 2021-01-11 19:59 ` Arnd Bergmann 2021-01-11 19:59 ` Arnd Bergmann 2021-01-11 21:15 ` Mattias Wallin 2021-01-11 21:15 ` Mattias Wallin 2021-01-11 21:47 ` Arnd Bergmann 2021-01-11 21:47 ` Arnd Bergmann 2021-01-11 13:13 ` Marc Gonzalez 2021-01-11 13:13 ` Marc Gonzalez 2021-01-11 17:29 ` Måns Rullgård 2021-01-11 17:29 ` Måns Rullgård 2021-01-11 21:50 ` Arnd Bergmann 2021-01-11 21:50 ` Arnd Bergmann 2021-01-12 8:23 ` Marc Gonzalez 2021-01-12 8:23 ` Marc Gonzalez 2021-01-11 14:22 ` Mark Salter 2021-01-11 14:22 ` Mark Salter 2021-01-11 15:00 ` Arnd Bergmann 2021-01-11 15:00 ` Arnd Bergmann 2021-01-11 14:44 ` Alexander Shiyan 2021-01-11 14:44 ` Alexander Shiyan 2021-01-11 14:58 ` Arnd Bergmann 2021-01-11 14:58 ` Arnd Bergmann 2021-01-11 16:23 ` Sylvain Lemieux 2021-01-11 16:23 ` Sylvain Lemieux 2021-01-11 22:17 ` Alexandre Belloni 2021-01-11 22:17 ` Alexandre Belloni 2021-01-11 19:58 ` Thomas Petazzoni 2021-01-11 19:58 ` Thomas Petazzoni 2021-01-11 20:10 ` Arnd Bergmann 2021-01-11 20:10 ` Arnd Bergmann 2021-01-11 20:25 ` Song Bao Hua (Barry Song) 2021-01-11 20:25 ` Song Bao Hua (Barry Song) 2021-01-12 8:41 ` Marc Gonzalez 2021-01-12 8:41 ` Marc Gonzalez 2021-01-13 10:30 ` Andy Shevchenko 2021-01-13 10:30 ` Andy Shevchenko 2021-01-13 11:02 ` Arnd Bergmann 2021-01-13 11:02 ` Arnd Bergmann 2021-01-13 16:14 ` [v2] " Arnd Bergmann 2021-01-13 19:00 ` Krzysztof Hałasa 2021-01-13 19:00 ` Krzysztof Hałasa 2021-01-14 8:51 ` Arnd Bergmann 2021-01-14 8:51 ` Arnd Bergmann 2021-01-15 7:08 ` Wei Xu 2021-01-15 7:08 ` Wei Xu 2021-01-15 9:26 ` Arnd Bergmann 2021-01-15 9:26 ` Arnd Bergmann 2021-01-15 11:09 ` Leizhen (ThunderTown) 2021-01-15 11:09 ` Leizhen (ThunderTown) 2021-01-15 12:04 ` Arnd Bergmann 2021-01-15 12:04 ` Arnd Bergmann 2021-01-18 10:46 ` Wei Xu 2021-01-18 10:46 ` Wei Xu 2021-01-13 22:27 ` Richard Z 2021-01-13 22:27 ` Richard Z 2021-02-05 13:37 ` Alexander Lobakin 2021-02-05 13:37 ` Alexander Lobakin 2021-10-23 17:44 ` Maciej W. Rozycki 2021-10-23 17:44 ` Maciej W. Rozycki 2021-01-12 2:05 tedheadster
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='CAK8P3a16dta82GOVZCcMgFokB4Mo6y6Vje=+5gUH-t-1ATQYUw@mail.gmail.com' \ --to=arnd@kernel.org \ --cc=arnd@arndb.de \ --cc=gerhard_pircher@gmx.net \ --cc=glaubitz@physik.fu-berlin.de \ --cc=jcmvbkbc@gmail.com \ --cc=linus.walleij@linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=linux-sh@vger.kernel.org \ --cc=sparclinux@vger.kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.