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

[Daniel Golle]

On Mon, Jan 07, 2019 at 02:39:26PM +0000, Jonas Gorski wrote:
> 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.

They sure do, cache size on small CPUs is a very finite resource
and having a kernel with debug symbols will make things slower, of
course. SWAP also makes every single malloc call more expensive and
is just as well only useful on devices with block storage (ok, and
zramswap, but lets not talk about that).

> 
> >
> > >
> > > 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.

But they are not even necessarily related, just closer to the vanilla
default config which is used eg. by Debian and most other Linux distros
so projects like LVM2 started to rely on them.
My goal here is to bring modern generic kernel features into OpenWrt,
they are quite unrelated apart from being left out for space reasons
and because for a minimal router/AP they are unneeded.

> 
> > 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.

I'll do within the next couple of days and post the results.


Cheers


Daniel

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

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