| Message ID | 20200521081825.1348844-1-rppt@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > (resendig for the correct address and with mailing list cc'ed, sorry for > the noise) > > Hi, > > Following the discussion at [1], I'm resending the patches that enable > memory model selection in menuconfig and such. > > These patches do not change the way the configuration is generated from the > defconfigs and they do not change explicit selection of SPARSEMEM for > platforms that have "select ARCH_ENABLE_SPARSEMEM". > > The mere change is that when a user runs an interactive configuration they > will be allowed to select between FLATMEM and SPARSMEM, which is not the > case today. > > There is indeed some awkwardness in, e.g. removal of > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in > mm/Kconfig imposes. > > For example, below is the diffs of the configurations generated with > 'make rpc_defconfig' and 'make defconfig': > > $ diff -s old/rpc_defconfig new/rpc_defconfig > Files old/rpc_defconfig and new/rpc_defconfig are identical > > $ diff -u old/defconfig new/defconfig > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300 > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300 > @@ -674,6 +674,9 @@ > CONFIG_AEABI=y > # CONFIG_OABI_COMPAT is not set > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y > +CONFIG_ARCH_FLATMEM_ENABLE=y > +CONFIG_ARCH_SPARSEMEM_ENABLE=y > CONFIG_HAVE_ARCH_PFN_VALID=y > CONFIG_HIGHMEM=y > CONFIG_HIGHPTE=y > @@ -1061,6 +1064,9 @@ > # > # Memory Management options > # > +CONFIG_SELECT_MEMORY_MODEL=y > +CONFIG_FLATMEM_MANUAL=y > +# CONFIG_SPARSEMEM_MANUAL is not set > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > CONFIG_ARCH_KEEP_MEMBLOCK=y Right, but the question is whether we want to offer flatmem for rpc. It isn't allowed today, and so far no one has said why it's a desirable change to make.
On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote: > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > (resendig for the correct address and with mailing list cc'ed, sorry for > > the noise) > > > > Hi, > > > > Following the discussion at [1], I'm resending the patches that enable > > memory model selection in menuconfig and such. > > > > These patches do not change the way the configuration is generated from the > > defconfigs and they do not change explicit selection of SPARSEMEM for > > platforms that have "select ARCH_ENABLE_SPARSEMEM". > > > > The mere change is that when a user runs an interactive configuration they > > will be allowed to select between FLATMEM and SPARSMEM, which is not the > > case today. > > > > There is indeed some awkwardness in, e.g. removal of > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in > > mm/Kconfig imposes. > > > > For example, below is the diffs of the configurations generated with > > 'make rpc_defconfig' and 'make defconfig': > > > > $ diff -s old/rpc_defconfig new/rpc_defconfig > > Files old/rpc_defconfig and new/rpc_defconfig are identical > > > > $ diff -u old/defconfig new/defconfig > > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300 > > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300 > > @@ -674,6 +674,9 @@ > > CONFIG_AEABI=y > > # CONFIG_OABI_COMPAT is not set > > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y > > +CONFIG_ARCH_FLATMEM_ENABLE=y > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y > > CONFIG_HAVE_ARCH_PFN_VALID=y > > CONFIG_HIGHMEM=y > > CONFIG_HIGHPTE=y > > @@ -1061,6 +1064,9 @@ > > # > > # Memory Management options > > # > > +CONFIG_SELECT_MEMORY_MODEL=y > > +CONFIG_FLATMEM_MANUAL=y > > +# CONFIG_SPARSEMEM_MANUAL is not set > > CONFIG_FLATMEM=y > > CONFIG_FLAT_NODE_MEM_MAP=y > > CONFIG_ARCH_KEEP_MEMBLOCK=y > > Right, but the question is whether we want to offer flatmem for rpc. > It isn't allowed today, and so far no one has said why it's a > desirable change to make. With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter) ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being enabled and since any of these machines explicitly selects ARCH_SPARSEMEM_ENABLE, the only available memory model would be SPARSEMEM. I played a bit with menuconfig and if any of the platforms requiring sparsemem is selected, the menu allowing the user to choose the memory model disappears. > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote: > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote: > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > > (resendig for the correct address and with mailing list cc'ed, sorry for > > > the noise) > > > > > > Hi, > > > > > > Following the discussion at [1], I'm resending the patches that enable > > > memory model selection in menuconfig and such. > > > > > > These patches do not change the way the configuration is generated from the > > > defconfigs and they do not change explicit selection of SPARSEMEM for > > > platforms that have "select ARCH_ENABLE_SPARSEMEM". > > > > > > The mere change is that when a user runs an interactive configuration they > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the > > > case today. > > > > > > There is indeed some awkwardness in, e.g. removal of > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in > > > mm/Kconfig imposes. > > > > > > For example, below is the diffs of the configurations generated with > > > 'make rpc_defconfig' and 'make defconfig': > > > > > > $ diff -s old/rpc_defconfig new/rpc_defconfig > > > Files old/rpc_defconfig and new/rpc_defconfig are identical > > > > > > $ diff -u old/defconfig new/defconfig > > > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300 > > > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300 > > > @@ -674,6 +674,9 @@ > > > CONFIG_AEABI=y > > > # CONFIG_OABI_COMPAT is not set > > > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y > > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y > > > +CONFIG_ARCH_FLATMEM_ENABLE=y > > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y > > > CONFIG_HAVE_ARCH_PFN_VALID=y > > > CONFIG_HIGHMEM=y > > > CONFIG_HIGHPTE=y > > > @@ -1061,6 +1064,9 @@ > > > # > > > # Memory Management options > > > # > > > +CONFIG_SELECT_MEMORY_MODEL=y > > > +CONFIG_FLATMEM_MANUAL=y > > > +# CONFIG_SPARSEMEM_MANUAL is not set > > > CONFIG_FLATMEM=y > > > CONFIG_FLAT_NODE_MEM_MAP=y > > > CONFIG_ARCH_KEEP_MEMBLOCK=y > > > > Right, but the question is whether we want to offer flatmem for rpc. > > It isn't allowed today, and so far no one has said why it's a > > desirable change to make. > > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter) > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being > enabled and since any of these machines explicitly selects > ARCH_SPARSEMEM_ENABLE, the only available memory model would be > SPARSEMEM. > > I played a bit with menuconfig and if any of the platforms requiring > sparsemem is selected, the menu allowing the user to choose the memory > model disappears. Ah, when either of these patforms will become a part of the multiplatform build, the only option for multiplatform build will be sparsemem. So it would be nice if somebody could check the cost of using sparsemem vs flatmem, espessially on low end machines. > > -- > > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote: > > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote: > > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > > > (resendig for the correct address and with mailing list cc'ed, sorry for > > > > the noise) > > > > > > > > Hi, > > > > > > > > Following the discussion at [1], I'm resending the patches that enable > > > > memory model selection in menuconfig and such. > > > > > > > > These patches do not change the way the configuration is generated from the > > > > defconfigs and they do not change explicit selection of SPARSEMEM for > > > > platforms that have "select ARCH_ENABLE_SPARSEMEM". > > > > > > > > The mere change is that when a user runs an interactive configuration they > > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the > > > > case today. > > > > > > > > There is indeed some awkwardness in, e.g. removal of > > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in > > > > mm/Kconfig imposes. > > > > > > > > For example, below is the diffs of the configurations generated with > > > > 'make rpc_defconfig' and 'make defconfig': > > > > > > > > $ diff -s old/rpc_defconfig new/rpc_defconfig > > > > Files old/rpc_defconfig and new/rpc_defconfig are identical > > > > > > > > $ diff -u old/defconfig new/defconfig > > > > --- old/defconfig 2020-05-20 17:51:01.832649705 +0300 > > > > +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300 > > > > @@ -674,6 +674,9 @@ > > > > CONFIG_AEABI=y > > > > # CONFIG_OABI_COMPAT is not set > > > > CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y > > > > +CONFIG_ARCH_SELECT_MEMORY_MODEL=y > > > > +CONFIG_ARCH_FLATMEM_ENABLE=y > > > > +CONFIG_ARCH_SPARSEMEM_ENABLE=y > > > > CONFIG_HAVE_ARCH_PFN_VALID=y > > > > CONFIG_HIGHMEM=y > > > > CONFIG_HIGHPTE=y > > > > @@ -1061,6 +1064,9 @@ > > > > # > > > > # Memory Management options > > > > # > > > > +CONFIG_SELECT_MEMORY_MODEL=y > > > > +CONFIG_FLATMEM_MANUAL=y > > > > +# CONFIG_SPARSEMEM_MANUAL is not set > > > > CONFIG_FLATMEM=y > > > > CONFIG_FLAT_NODE_MEM_MAP=y > > > > CONFIG_ARCH_KEEP_MEMBLOCK=y > > > > > > Right, but the question is whether we want to offer flatmem for rpc. > > > It isn't allowed today, and so far no one has said why it's a > > > desirable change to make. > > > > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter) > > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being > > enabled and since any of these machines explicitly selects > > ARCH_SPARSEMEM_ENABLE, the only available memory model would be > > SPARSEMEM. > > > > I played a bit with menuconfig and if any of the platforms requiring > > sparsemem is selected, the menu allowing the user to choose the memory > > model disappears. > > Ah, when either of these patforms will become a part of the > multiplatform build, the only option for multiplatform build will be > sparsemem. > So it would be nice if somebody could check the cost of using sparsemem > vs flatmem, espessially on low end machines. Do you think they will become part of multiplatform? If they're low-end machines, then adding: (a) the additional memory overhead of a multiplatform kernel (b) the additional runtime overhead of the complexities of multiplatform kernels is surely an odd thing to do, especially when few really care about these platforms becoming part of a multiplatform kernel, except those who like the idea of multiplat.
On Thu, May 21, 2020 at 03:50:20PM +0100, Russell King - ARM Linux admin wrote: > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > > On Thu, May 21, 2020 at 03:33:29PM +0300, Mike Rapoport wrote: > > > On Thu, May 21, 2020 at 01:03:08PM +0100, Russell King - ARM Linux admin wrote: > > > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > > > > (resendig for the correct address and with mailing list cc'ed, sorry for > > > > > the noise) > > > > > > > > > > Hi, > > > > > > > > > > Following the discussion at [1], I'm resending the patches that enable > > > > > memory model selection in menuconfig and such. > > > > > > > > > > These patches do not change the way the configuration is generated from the > > > > > defconfigs and they do not change explicit selection of SPARSEMEM for > > > > > platforms that have "select ARCH_ENABLE_SPARSEMEM". > > > > > > > > > > The mere change is that when a user runs an interactive configuration they > > > > > will be allowed to select between FLATMEM and SPARSMEM, which is not the > > > > > case today. > > > > > > > > > > There is indeed some awkwardness in, e.g. removal of > > > > > ARCH_SPARSEMEM_DEFAULT, but this is what memory model selection logic in > > > > > mm/Kconfig imposes. > > > > > > > > > Right, but the question is whether we want to offer flatmem for rpc. > > > > It isn't allowed today, and so far no one has said why it's a > > > > desirable change to make. > > > > > > With ARCH_RPC=y (or ARCH_SA1100 or ARCH_EP93XX for that matter) > > > ARCH_MULTIPLATFORM=n which prevents ARCH_SELECT_MEMORY_MODEL from being > > > enabled and since any of these machines explicitly selects > > > ARCH_SPARSEMEM_ENABLE, the only available memory model would be > > > SPARSEMEM. > > > > > > I played a bit with menuconfig and if any of the platforms requiring > > > sparsemem is selected, the menu allowing the user to choose the memory > > > model disappears. > > > > Ah, when either of these patforms will become a part of the > > multiplatform build, the only option for multiplatform build will be > > sparsemem. > > So it would be nice if somebody could check the cost of using sparsemem > > vs flatmem, espessially on low end machines. > > Do you think they will become part of multiplatform? > > If they're low-end machines, then adding: > > (a) the additional memory overhead of a multiplatform kernel > (b) the additional runtime overhead of the complexities of multiplatform > kernels > > is surely an odd thing to do, especially when few really care about > these platforms becoming part of a multiplatform kernel, except those > who like the idea of multiplat. I honestly don't know, it was Arnd who was talking about adding ep93xx to multiplat. So, probably better phrasing would have been "if either of these patforms will become a part of the multiplatform build...". Anyway, benchmarking sparsemem vs flatmem on a platform that is already a part of multiplat might be useful to understand whether we need both of them or we can simply make everything use sparsemem. > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > (resendig for the correct address and with mailing list cc'ed, sorry for > the noise) There are two patches in the patch system, submitted within minutes of each other, with the same summary "Allow either FLATMEM or SPARSEMEM on the multiplatform build" but the patch and commit messages are different. I guess the summary for one of the patches is wrong?
On Tue, May 26, 2020 at 12:18:04PM +0100, Russell King - ARM Linux admin wrote: > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > (resendig for the correct address and with mailing list cc'ed, sorry for > > the noise) > > There are two patches in the patch system, submitted within minutes > of each other, with the same summary "Allow either FLATMEM or > SPARSEMEM on the multiplatform build" but the patch and commit messages > are different. I guess the summary for one of the patches is wrong? Oops, my mistake. The patch 8979/1 should have "ARM: Remove redundant ARCH_SPARSEMEM_DEFAULT setting" in its subject. Sorry. > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
On Tue, May 26, 2020 at 02:42:16PM +0300, Mike Rapoport wrote: > On Tue, May 26, 2020 at 12:18:04PM +0100, Russell King - ARM Linux admin wrote: > > On Thu, May 21, 2020 at 11:18:23AM +0300, Mike Rapoport wrote: > > > (resendig for the correct address and with mailing list cc'ed, sorry for > > > the noise) > > > > There are two patches in the patch system, submitted within minutes > > of each other, with the same summary "Allow either FLATMEM or > > SPARSEMEM on the multiplatform build" but the patch and commit messages > > are different. I guess the summary for one of the patches is wrong? > > Oops, my mistake. > > The patch 8979/1 should have "ARM: Remove redundant > ARCH_SPARSEMEM_DEFAULT setting" in its subject. Thanks; updated the database with that.
Hi Russell, On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > > Ah, when either of these patforms will become a part of the > > multiplatform build, the only option for multiplatform build will be > > sparsemem. > > So it would be nice if somebody could check the cost of using sparsemem > > vs flatmem, espessially on low end machines. > > Do you think they will become part of multiplatform? > > If they're low-end machines, then adding: > > (a) the additional memory overhead of a multiplatform kernel > (b) the additional runtime overhead of the complexities of multiplatform > kernels > > is surely an odd thing to do, especially when few really care about > these platforms becoming part of a multiplatform kernel, except those > who like the idea of multiplat. The fallacy of "multi-platform", again? Isn't it a requirement for any new ARM v7-A platforms to be part of ARCH_MULTI_V7, even if it's a low-end machine? Gr{oetje,eeting}s, Geert
On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > > > Ah, when either of these patforms will become a part of the > > > multiplatform build, the only option for multiplatform build will be > > > sparsemem. > > > So it would be nice if somebody could check the cost of using sparsemem > > > vs flatmem, espessially on low end machines. > > > > Do you think they will become part of multiplatform? > > > > If they're low-end machines, then adding: > > > > (a) the additional memory overhead of a multiplatform kernel > > (b) the additional runtime overhead of the complexities of multiplatform > > kernels > > > > is surely an odd thing to do, especially when few really care about > > these platforms becoming part of a multiplatform kernel, except those > > who like the idea of multiplat. > > The fallacy of "multi-platform", again? > > Isn't it a requirement for any new ARM v7-A platforms to be part of > ARCH_MULTI_V7, even if it's a low-end machine? What does ARMv7 have to do with this thread, that is discussing the older ARMv4 platforms? I find your comments above irrelevent to this discussion, and seems to be worded to provoke a reaction. Not playing.
Hi Russell, On Tue, Jun 2, 2020 at 2:22 PM Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote: > On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote: > > On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin > > <linux@armlinux.org.uk> wrote: > > > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > > > > Ah, when either of these patforms will become a part of the > > > > multiplatform build, the only option for multiplatform build will be > > > > sparsemem. > > > > So it would be nice if somebody could check the cost of using sparsemem > > > > vs flatmem, espessially on low end machines. > > > > > > Do you think they will become part of multiplatform? > > > > > > If they're low-end machines, then adding: > > > > > > (a) the additional memory overhead of a multiplatform kernel > > > (b) the additional runtime overhead of the complexities of multiplatform > > > kernels > > > > > > is surely an odd thing to do, especially when few really care about > > > these platforms becoming part of a multiplatform kernel, except those > > > who like the idea of multiplat. > > > > The fallacy of "multi-platform", again? > > > > Isn't it a requirement for any new ARM v7-A platforms to be part of > > ARCH_MULTI_V7, even if it's a low-end machine? > > What does ARMv7 have to do with this thread, that is discussing the > older ARMv4 platforms? I find your comments above irrelevent to > this discussion, and seems to be worded to provoke a reaction. Sorry, I used ARMv7 as an example, as it's rare for any new ARMv4 platforms to show up. But the recently introduced sam9x60 (ARMv5) is part of ARCH_MULTI_V5, and I expect it will be used with less than the 256 MiB provided on the dev board. Nevertheless, there's a movement to convert everything to ARCH_MULTI_V* where possible. So it matters for all variants. Gr{oetje,eeting}s, Geert
On Tue, Jun 02, 2020 at 02:37:45PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > On Tue, Jun 2, 2020 at 2:22 PM Russell King - ARM Linux admin > <linux@armlinux.org.uk> wrote: > > On Tue, Jun 02, 2020 at 02:18:48PM +0200, Geert Uytterhoeven wrote: > > > On Thu, May 21, 2020 at 4:50 PM Russell King - ARM Linux admin > > > <linux@armlinux.org.uk> wrote: > > > > On Thu, May 21, 2020 at 05:07:45PM +0300, Mike Rapoport wrote: > > > > > Ah, when either of these patforms will become a part of the > > > > > multiplatform build, the only option for multiplatform build will be > > > > > sparsemem. > > > > > So it would be nice if somebody could check the cost of using sparsemem > > > > > vs flatmem, espessially on low end machines. > > > > > > > > Do you think they will become part of multiplatform? > > > > > > > > If they're low-end machines, then adding: > > > > > > > > (a) the additional memory overhead of a multiplatform kernel > > > > (b) the additional runtime overhead of the complexities of multiplatform > > > > kernels > > > > > > > > is surely an odd thing to do, especially when few really care about > > > > these platforms becoming part of a multiplatform kernel, except those > > > > who like the idea of multiplat. > > > > > > The fallacy of "multi-platform", again? > > > > > > Isn't it a requirement for any new ARM v7-A platforms to be part of > > > ARCH_MULTI_V7, even if it's a low-end machine? > > > > What does ARMv7 have to do with this thread, that is discussing the > > older ARMv4 platforms? I find your comments above irrelevent to > > this discussion, and seems to be worded to provoke a reaction. > > Sorry, I used ARMv7 as an example, as it's rare for any new ARMv4 > platforms to show up. But the recently introduced sam9x60 (ARMv5) is > part of ARCH_MULTI_V5, and I expect it will be used with less than the > 256 MiB provided on the dev board. > > Nevertheless, there's a movement to convert everything to ARCH_MULTI_V* > where possible. So it matters for all variants. First, please understand that I have nothing against multiplatform. What I do have problems with is the "lets move everything to multiplatform" without fully reasoning it out, especially when it comes to older platforms that have limited attraction for the whole motivation behind multiplatform, which is the convenience of distributions. multiplatform is the current fad-de-jour, and everyone is in a "you MUST convert EVERYTHING to it, because it's the best thing since sliced bread". multiplatform comes with it a load of forced-enabled options that are force-enabled. Should RiscPC be forced to have the common clock support built into the kernel, when it doesn't' have _any_ controllable clocks, when it's likely that the machines have limited memory available? Yes, I have recently booted the RiscPC with a 5.x kernel, and no, it didn't need very much fixing, the code is quite *stable* (oh, I blaspheme, we can't have stable code in Linux, we must change it every five minutes.) I think, maybe, you should leave these decisions to people who actually have the platforms, know them inside out, and can assess whether conversion really makes sense or not, rather than blindly joining the zombie march repeating "multiplatform is great, everything must be multiplatform". What is patently obvious is that in Linux, there is no tolerance of someone who has a differing view, and they end up receiving reaction provoking comments designed to inflame the situation. Difference of opinion must be suppressed at all costs!
--- old/defconfig 2020-05-20 17:51:01.832649705 +0300 +++ new/defconfig 2020-05-20 18:15:21.084385880 +0300 @@ -674,6 +674,9 @@ CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y +CONFIG_ARCH_SELECT_MEMORY_MODEL=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_HAVE_ARCH_PFN_VALID=y CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y @@ -1061,6 +1064,9 @@ # # Memory Management options # +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_ARCH_KEEP_MEMBLOCK=y