On Thu, May 4, 2023 at 7:35 AM Elliott Mitchell <ehem+open...@m5p.com> wrote: > On Thu, May 04, 2023 at 03:50:05AM +0100, Daniel Golle wrote: > > On Wed, May 03, 2023 at 06:36:10PM -0700, Elliott Mitchell wrote: > > > On Tue, May 02, 2023 at 02:45:43AM +0200, Alberto Bursi wrote: > > > > On 26/04/23 22:17, Elliott Mitchell wrote:
> Something is very wrong here. > > Question is whether it is deliberate versus accidental. > > One possibility is you last looked at an OpenWRT x86 5.10 kernel and > figured the number would be roughly in line with 5.15. In this case > there was a rather drastic increase in size between 5.10 and 5.15 for > x86. > > Another possibility which comes to mind is that is pretty close to the > x86 5.15 compressed image size. I would expect you to be aware modern > data compression algorithms are fairly effective and can often provide > substantial reductions. I suppose you could be unaware of this, but > given how well known this is I would be left suspecting deliberate > distortion. > > The last generic OpenWRT x86 5.15 image I built less than a week ago > produced a roughly 28MB vmlinux.bin file. Some of that disappears since > initialization portions will be freed after boot, but this is fairly > representative of runtime use (additional will be used for what is found > during boot). > > My most recent OpenWRT based image which was moderately adapted to a > specific target (running in a Xen VM) was 18MB. *That* is substantial > enough to go after. Here are memory figures for a fully initialized OpenWrt x86/64 QEMU systems. Very easy for anyone capable of proposing kernel configuration patches to try themselves. $ qemu-system-x86_64 -nodefaults -smp 2 -m 128 -vga std -nic user,model=virtio -nic user,model=virtio -drive file=openwrt.img,format=raw,if=virtio # opkg update && opkg install luci && reboot https://downloads.openwrt.org/releases/22.03.5/targets/x86/64/openwrt-22.03.5-x86-64-generic-ext4-combined.img.gz Kernel: 5.10.176 /boot/vmlinuz size: 5.0M Memory used after boot settles: ~44M https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-ext4-combined.img.gz Kernel: 5.15.110 /boot/vmlinuz size: 5.6M Memory used after boot settles: ~46M (Caveat: snapshot build) > Is OpenWRT/x86 a networking device Linux distribution? > Yet again, I'm asking the question: What is THE goal of OpenWRT/86? > Is OpenWRT/x86 aiming to be a desktop Linux distribution? No, but everything else is as modular as possible through packages etc so people can do whatever they want with it. Even routing packets. Good container support will mean the OpenWrt distribution itself won't ever need to grow into something like Debian and can stay focused on embedded/networking use cases. From https://openwrt.org/ : > The OpenWrt Project is a Linux operating system targeting embedded devices. > Instead of trying to create a single, static firmware, OpenWrt provides a > fully writable filesystem with package management. This frees you from the > application selection and configuration provided by the vendor and allows you > to customize the device through the use of packages to suit any application. > For developers, OpenWrt is the framework to build an application without > having to build a complete firmware around it; for users this means the > ability for full customization, to use the device in ways never envisioned > Is OpenWRT/x86 a developer test simulator for "real" OpenWRT targets? It is a real target that people and companies use daily for their packet routing needs. Also, the best test target would be... a real target. > Is OpenWRT/x86 a networking device Linux distribution? More or less I'd say. OpenWRT/x86 is just a build of OpenWrt that runs on x86. so it's mainly focused on providing a good out-of-the-box network router. Plug in NICs and they just show up. It just so happens that the x86 platform/ecosystem has more diverse boot-related hardware than specific isolated targets, which will make the kernels a little bigger than other focused targets. You can choose to use a serial console, or choose to use a VGA console. It simply works out-of-the-box in a few minutes on most x86 hardware or x86 VMs. Wonderful. I'd say this is the single most important feature of the x86 target, that it just works out of the box. Its now 2023. No-one has time to be recompiling kernels when they just need a reliable router now while juggling work and family. If you handed over a work-critical networking appliance with hand-rolled kernels to your work colleagues to maintain, you might as well have handed them a barnfire. So its good the x86 targets just work without any messing due to being too lean. --- The original issue raised in these threads is centered around the perception that the default build/install of the x86 targets have excessive memory usage in different scenarious, along with various patches and suggestions for cutting this down. However simple testing like above shows this isn't really a problem. > I can state my goal/hope for OpenWRT/x86. The *WRT Linux distributions > were so named for originally targeting the LinkSys WRT54G. This was a > small AP, so one might expect builds to be for small APs. By today's > standards 128MB RAM and 16MB of storage is relatively small. > > Problem is instead of the recommended 128MB memory, 16MB of storage > (https://openwrt.org/supported_devices/432_warning) the virtualization > examples (https://openwrt.org/docs/guide-user/virtualization/start) are > suggesting massively more memory. 256MB (small Xen example), 512MB > (VMware OpenWRT/15.05) or 1GB (Qemu examples). By your own standards, the current x86 builds as shown above already meet the "relatively small" requirements. Great :) > KVM/Qemu, Hyper-V and Xen are likely the bigger gains. My impression is > the Virtio stuff is fairly encompassing and thus a drag on others. While > Hyper-V is pretty complex and also a major drag on others. Meanwhile Xen > is very small and thus gets dragged down by others. Maybe there is a case for a separate all-in-one virt profile if it fills up with exotic things, but as others have said IMHO its nicer to stay with a flexible "run-everywhere" image, unless there is a very clear reason not to. I'm sure no-one would mind some more virt storage drivers in the current x86/64 builds, but something like Xen might only be possible with a separate kernel/target. Anyway, this is going around in circles, so I'll leave my input there. _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
