[OpenWrt-Devel] [PATCH] config: enable some useful features on !SMALL_FLASH devices

[Jonas Gorski]

On Mon, 7 Jan 2019 at 14:21, Daniel Golle <daniel at makrotopia.org> wrote:
>
> On Mon, Jan 07, 2019 at 01:17:34PM +0000, Jonas Gorski wrote:
> > On Mon, 7 Jan 2019 at 11:42, Petr Štetiar <ynezz at true.cz> wrote:
> > >
> > > Daniel Golle <daniel at makrotopia.org> [2019-01-07 10:03:09]:
> > >
> > > Hi,
> > >
> > > > One. The MT7621 EVB. The TP-LINK RE350 v1 can probably be converted to
> > > > a more sane flash partition layout to gain another megabyte or so.
> > >
> > > I've looked only at mt7621, so this was just example from one subtarget of
> > > ramips target. So I tend to believe, that there's quite more such cases hidden
> > > in the tree. Please correct me if I'm wrong.
> > >
> > > > Why specific devices? Wouldn't all devices with the resources (which
> > > > boils down to !SMALL_FLASH) be potentially more useful with those
> > > > kernel features enabled?
> > >
> > > You currently can't use !SMALL_FLASH, because this is target/subtarget
> > > specific feature, not per device feature. I think, that in order to use this
> > > feature, you would need to convert/fix all devices like that TP-Link RE350
> > > from all (sub)targets into tiny subtarget and then you could freely use
> > > !SMALL_FLASH.
> >
> > I agree with not abusing small_flash for that. It has a clear defined
> > meaning, and shouldn't have unrelated side effects.
>
> So what else would the SMALL_FLASH symbol be used for then?
> A quick grep reveals that currently already quite a few kernel config
> defaults are set according to SMALL_FLASH, see
>
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_SWAP
> origin/master:Config-kernel.in- bool "Support for paging of anonymous memory (swap)"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_KALLSYMS
> origin/master:Config-kernel.in- bool "Compile the kernel with symbol table information"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-
> origin/master:Config-kernel.in-config KERNEL_DEBUG_INFO
> origin/master:Config-kernel.in- bool "Compile the kernel with debug information"
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> --
> origin/master:Config-kernel.in-config KERNEL_ELF_CORE
> origin/master:Config-kernel.in- bool "Enable process core dump support"
> origin/master:Config-kernel.in- select KERNEL_COREDUMP
> origin/master:Config-kernel.in: default y if !SMALL_FLASH
> ...

Most of these option only influence the size of the kernel, and have
no further runtime side effects. Also small_flash has impact on the
compression options used.

>
> >
> > I think a new opt-in symbol for those targets with hardware
> > virtualization support and/or beefy enough cpus would make more sense.
> > Those virtualization options (probably) don't come for free, they will
> > have also a memory and performance impact even when not actively used.
> > How much that is (and if this assumption is true) would be nice to
> > have in the PR/patch for it.
>
> This is not about virtualization and none of the features selected
> requires any special hardware support apart from the few extra
> kilobytes of flash and memory. You are still right, it doesn't come
> all for free at runtime in terms of CPU cycles, but the impact is
> hardly measurable.
>
> But sure, I understand that this can be opt-in, so lets call it
> 'full_kernel' or something like that and have target maintainers
> decide themselves. In the picture I get after browsing through
> all targets, it would still end up such that
> full_kernel == !small_flash is true for all cases.

"Full kernel" really has no real meaning and would describe
everything. The name should clearly describe the (non-default) feature
set it enables.

> And sure, I can carry out some size measurements and compare memory
> allocation after boot. I'm sure the run-time CPU impact is hardly
> measurable at all.

Please do so especially on low end devices. Maybe something like
routing throughput with/without.


Regards
Jonas

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel