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

[Jonas Gorski]

On Wed, 6 Feb 2019 at 13:12, Jonas Gorski <jonas.gorski at gmail.com> wrote:
>
> On Tue, 15 Jan 2019 at 15:42, Daniel Golle <daniel at makrotopia.org> wrote:
> >
> > Hi Jonas,
> >
> > On Mon, Jan 07, 2019 at 03:48:29PM +0100, Daniel Golle wrote:
> > > 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.
> >
> > Kernel size increases by about 90kB (lzma compressed).
> > Memory consumption just after boot (ironically) seems to be lower with
> > those options enabled, however, it's all in the range of +/- 100kB.
> > Network performance seems to be exactly identical.
> >
> > (tested on ar71xx based on latest master commit)
>
> I gave it my own test with a bcm6328 (320 MHz), and did see some
> variance in network performance, but only a few percent. Might have
> been differences from code changing alignments to cache lines or so.
>
> I did see a more pronounced memory change though, in the range of ~500
> kB less free memory. Might be relevant for 32 MiB devices.
>
> Since growing kernels breaking boards with u-boot not loading enough
> from flash is a common enough occurrence, I'd vote for deferring this
> change until we branched for the upcoming release, to not introduce
> additional board breakage shortly before that. After that we'll get
> enough breakage there from the 4.19 switch anyway, so we might then
> also up the official minimum requirement to 8 MiB flash.

Since 19.07 is now branched, I have no objections anymore to adding this patch.


Regards
Jonas

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