Objective of OpenWRT/x86?

[Elliott Mitchell]

On Thu, Apr 27, 2023 at 05:04:36AM +0100, Joseph Mullally wrote:
> One nice feature for users of the "x86/64" and similar builds are that
> they work out of the box on most generic hardware or virtualization
> platforms. I use it on real hardware and KVM with device passthrough,
> and it was very easy to set up. I'm guessing this is far more common
> than speculative high density VM deployments.

"on most generic hardware or virtualization platforms" means lots of
common and quite a number of uncommon drivers are included.  Which in
turn means the kernel is quite large.

I'm not thinking of a high-density VM deployment.  I'm looking at the
list of built-in drivers and seeing many which will perhaps only be used
by 25% of installations.

> It makes more sense to make a new lightweight VM profile rather than
> chopping stuff out of the generic ones.

More likely lightweight VM /configurations/.  Xen, VMware, KVM and HyperV
each want one.  Issue is drivers guaranteed to be used by one VM will add
megabytes of wasted memory to the kernel of another.

The generic kernel does serve as a starting point.  Should there perhaps
be a target/linux/x86vm directory?

> But is one needed, and how much memory would be saved? Have you
> actually tried running the "x86/64" image with 128MB ram under QEMU?
> Default 22.03.4 install shows 45MB used. With "wpad-openssl" and
> "kmod-mac80211-hwsim", its up to 53MB. These requirements rise
> depending on load. I'm guessing those memory figures in the wiki docs
> are just arbitrary, showing people they can run cool stuff.

That could be.  Might simply be the wiki needs to have numbers adjusted
downwards to reflect how much memory a reasonable installation needs
instead of an advanced doing all the things installation.

> If memory usage optimization is the goal, I suggest these discussions
> and patches be tested and informed by real measurements in that area,
> to discuss whether the tradeoffs with compatability are worth it.

Isolating each kernel configuration change can be slightly tricky.  If 3
things depend on something large, it may appear removing the first two
options has minimal effect, but the third has a gigantic effect.  When
the truth is all 3 were important.

A few kernel configuration builds:

OpenWRT: 28039448 bytes
allnoconfig: 3101272 bytes
xen.config: 14385480 bytes

At one point I tried building one of the ARM targets.  The resultant
kernel was ~10MB.  Due to x86 being around a long time and GCC having
received a lot of work on x86, x86 builds of the same source tend to be
distinctly smaller on x86.  With that context the above numbers are
underwhelming.  My only hope is allnoconfig strips out boot support for
most environments and most of the delta is ACPI/UEFI/PNP.

While typing about `make allnoconfig`, one of OpenWRT's patches appears
to break "allnoconfig".  Specifically something is trying to call
`skb_free_reason()`, but that function has been left out.  Appears
the function 

In particular lib/kobject_uevent.c calls the function kfree_skb(), which
is declared in include/linux/skbuff.h.  This is an inline which in turn
calls kfree_skb_reason(), which is normally defined in net/core/skbuff.c
yet CONFIG_NET=n removes this file.  Seems one of the x86 patches needs
some sort of adjustment.


As far as creating a slimmed-down VM kernel configuration.  Removing AGP
support doesn't gain much itself, but then disabling DRM support saves
2203648 bytes.  Turning USB support into modules is another 2MB.  I've
gotten a potentially viable Xen kernel down to 23MB, but I hope to push
at least somewhat further.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445