On Thursday, December 8, 2022, Daniel P. Berrangé berrange@redhat.com wrote:
On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote:
On Thursday, December 8, 2022, Adam Williamson <
adamwill@fedoraproject.org>
wrote:
On Thu, 2022-12-08 at 12:58 +0000, Peter Robinson wrote:
I've done a few passes, dropping a bunch of older firmware upstream that are no longer supported in any stable kernel release, also a bunch of de-dupe and linking of files rather than shipping of
multiple
copies of the same firmware. It's improved things a bit,
unfortunately
a lot of the dead firmware was tiny compared to say average modern devices like GPUs or WiFI.
The problem with a lot of the firmware, and with the new nvidia "open driver" which shoves a lot of stuff into firmware in order to have an upstreamable driver apparently the firmwares there are going to be 30+Mb each, is that they're needed to bring up graphics/network etc
to
even just install so I don't know how we can get around this and
still
have a device work enough to be able to install the needed firmware across the network.
Ideas on how to solve that problem welcome.
Sorry if this is way off, but - do we need the GPU firmwares to run a graphical install on the fallback path, just using the framebuffer set up by the firmware? How crazy would it be to just do that - ship the installer env with no GPU firmware?
That would be very crazy, as you will have a degraded user experience (laggy UI, wrong resolution, ...) to save a couple of megabytes that are
a
non issue for today's hardware.
Please bear in mind the difference between bare metal and virtual machines. The bare metal machine may have 32 GB of RAM, making a 800 MB install image a non-issue. For a public cloud virtual machine though, this could bump your VM sizing up 1 level from 2 GB quota to a 4 GB RAM quota, with correspondingly higher price point. Now most people probably don't run the installer in a public cloud, preferring pre-built disk images. Even in a local machine though, you may be using most of your 32 GB of RAM for other things (well firefox/chrome), so allowing extra for the VM is not without resource cost. If we could figure out a way to knock a few 100 MB off the installer RAM requirements that is valuable.
The problem I see here is not the presence of the firmware on the image, but the fact that it seems to be loaded into memory despite not being used.
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/ dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/ dberrange :| _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject. org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@ lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora- infrastructure/new_issue
On Thu, 2022-12-08 at 20:23 +0100, drago01 wrote:
Please bear in mind the difference between bare metal and virtual machines. The bare metal machine may have 32 GB of RAM, making a 800 MB install image a non-issue. For a public cloud virtual machine though, this could bump your VM sizing up 1 level from 2 GB quota to a 4 GB RAM quota, with correspondingly higher price point. Now most people probably don't run the installer in a public cloud, preferring pre-built disk images. Even in a local machine though, you may be using most of your 32 GB of RAM for other things (well firefox/chrome), so allowing extra for the VM is not without resource cost. If we could figure out a way to knock a few 100 MB off the installer RAM requirements that is valuable.
The problem I see here is not the presence of the firmware on the image, but the fact that it seems to be loaded into memory despite not being used.
This is the direction Daniel was thinking down. I'm waiting for someone with more expertise to reply, but I suspect the reply is going to be along the lines of "yes, we *can* do that, but it's somewhat tricky work that involves thinking about lots of paths that aren't obvious, and somebody would need to dedicate their time to working on that".
Hi,
On Thu, Dec 8, 2022 at 2:55 PM Adam Williamson adamwill@fedoraproject.org wrote:
This is the direction Daniel was thinking down. I'm waiting for someone with more expertise to reply, but I suspect the reply is going to be along the lines of "yes, we *can* do that, but it's somewhat tricky work that involves thinking about lots of paths that aren't obvious, and somebody would need to dedicate their time to working on that".
Presumably we could package the firmware separately and just unpack it into place from a udev rule when the hardware is detected?
But first, do we actually know this is a problem? I think you're saying squashfs loads the whole decompressed image into memory, but my expectation prior to your mail was that it performs I/O on the usb stick (with a cache in between). If my intuition was right and files only hit ram when accessed, then it seems like this is pretty much not an issue, right?
Do you have stats on memory usage when running in a live environment?
desktop@lists.fedoraproject.org
-
Adam Williamson -
drago01 -
Ray Strode