On 29-08-2022 10:49, Hans de Goede wrote:
<snip>
I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.
I still have quite a few x86_64 tablets with only 1G RAM, so I personally
definitely care about this.
With that said I do regularly run dnf on them without issues,
although I think most of the 1G models I have are still at F35...
Still I wonder why this is an issue in some cases:
1. ZRAM helps a lot here, but I guess with containers when limiting them
to 1G you really only get 1G since ZRAM works on the system level not
the container level. In the VM case though ZRAM should help, is ZRAM
enabled ? ZRAM is enabled by default for Workstation installs, but
maybe not in other installs ?
I ran into this on a RaspberryPi 3 with 1G of RAM and 1G of zram. That's
the default configuration of F35 (Server Edition). I since added a 512M
swapfile to the setup and my last 'dnf upgrade', yesterday was not
killed by systemd.
When dnf was killed by systemd-oomd, I was able to switch to microdnf,
which allowed me to continue.
2. Maybe there are some other processes also taking up more RAM
then expected causing extra memory pressure ?
That's possible. But the main issue appears to be with dnf. For ARM it's
currently recommended to turn off dnf-makecache [1], which I actually
intended to use to check for security related updates.
But there's PackageKit also running on the system, triggered by Cockpit
update checks. PackageKit is keeping its own cache, iirc, and it's
equally resource hungry.
Maybe settling for one package backend would be an option at least for
the Server Edition? Personally, I could do without cockpit-packagekit,
but others might want a replacement using (lib)dnf.
Bottom line: I care about this getting solved. But, if documented,
there's no need for it to block F37 (Beta).
[1]
https://fedoraproject.org/wiki/Architectures/ARM/Fedora_Linux_35#Tips_&_Tricks
-- Sandro
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
