Re: systemd-oomd issues on desktop
On Tue, Jun 14, 2022 at 03:47:58PM +0100, Dave Jones wrote: > On Fri, Jun 10, 2022 at 08:16:15PM +0200, Sebastien Bacher wrote: > > Le 09/06/2022 à 21:19, Dan Streetman a écrit : > > > Personally, I think this is the correct option. 1GB is not a good > > > default swap size. > > > > Did we ever consider doing the same than fedora is doing there? > > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > One minor data point here: yes, at least on the Pi images where zswap is > activated by default. > > Some background context: one goal on jammy was to make the desktop viable on > the Pi 4 with 2GB of RAM (though not the 1GB). Given that the Pi desktop > images ship with 1GB of swap (so we know there definitely *is* a swap-file You actually mean no. See what Fedora did is they disabled swapfiles/swap partitions, and instead only created a zram device and swap on that, so they only have compressed memory as swap. But also with that the case, one has to wonder how systemd-oomd ever worked for them without any (large) physical swap - they should have hit the same issues we did. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd-oomd issues on desktop
On Fri, Jun 10, 2022 at 08:16:15PM +0200, Sebastien Bacher wrote: Le 09/06/2022 à 21:19, Dan Streetman a écrit : Personally, I think this is the correct option. 1GB is not a good default swap size. Did we ever consider doing the same than fedora is doing there? https://fedoraproject.org/wiki/Changes/SwapOnZRAM One minor data point here: yes, at least on the Pi images where zswap is activated by default. Some background context: one goal on jammy was to make the desktop viable on the Pi 4 with 2GB of RAM (though not the 1GB). Given that the Pi desktop images ship with 1GB of swap (so we know there definitely *is* a swap-file that zswap can utilize), that the machine doesn't have upgradeable RAM (though I suppose moving one's storage to a bigger Pi is roughly equivalent), and that I knew oomd was being contemplated, I did a day of testing the 2GB Pi 4 with and without zswap active, and the difference was pretty stark (without zswap the system really didn't feel "useable" due to frequent oomd kills of ff). That said, I'm contemplating bumping the swap (which is allocated on first boot on the Pi images since jammy) up to 2GB for kinetic as that seems to reduce the number of oomd kills noticeably on the more memory constrained Pis (though just anecdotally; I haven't sat down and recorded/analyzed this yet). Dave. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding logo images to base-files?
On Tuesday, June 14, 2022 6:06:21 AM PDT Sebastien Bacher wrote: > Le 14/06/2022 à 02:09, Erich Eickmeyer a écrit : > >> Just chiming-in here from a Flavor Lead perspective. It seems like this > >> could be something that could be implemented via update-alternatives, > >> similar to how plymouth themes and distributor-logo and are controlled. > > How are flavor handling /etc/os-release today? LOGO isn't the only thing > there they might want to set differently from Ubuntu (pretty_name, > support_url, bug_report_url are other examples). > Currently, we're not, and I for one am OK with it. As far as I am concerned, the OS *should* be reporting itself as Ubuntu since it *is* Ubuntu. We're not trying to disguise ourselves as a different distro, but as a different out-of- the-box configuration of said distro. In Studio, we don't try to hide that as much as other flavors might. That said, I don't know of a single flavor that does change-out /etc/os-release. -- Erich Eickmeyer Project Leader - Ubuntu Studio Member - Ubuntu Community Council signature.asc Description: This is a digitally signed message part. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Adding logo images to base-files?
Hey, Le 14/06/2022 à 02:09, Erich Eickmeyer a écrit : Just chiming-in here from a Flavor Lead perspective. It seems like this could be something that could be implemented via update-alternatives, similar to how plymouth themes and distributor-logo and are controlled. How are flavor handling /etc/os-release today? LOGO isn't the only thing there they might want to set differently from Ubuntu (pretty_name, support_url, bug_report_url are other examples). Using alternatives for the logo here sounds like the wrong solution, it's the os-release that should be diverted instead. Cheers, Sebastien Bacher -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd-oomd issues on desktop
On Mon, Jun 13, 2022 at 8:19 AM Lukas Märdian wrote: > I wonder if we could use a more selective approach, though, using > "OOMScoreAdjust=" in the systemd.exec environment (i.e. Gnome-Shell > launcher in Ubuntu's context, as sd-oomd is currently only enabled on > Ubuntu Desktop) [2], to reduce the probability of certain "important" > apps being killed first, e.g. by maintaining an allow-list of such apps. IIUC, OOMScoreAdjust only influences the behavior of the kernel OOM killer, not systemd-oomd. In any case, I do agree that a "selective approach" might improve the current situation (this is what I tried to convey in option (2)). The ManagedOOMPreference[1] option exists, but this property is ignored if the unit's cgroup is not owned by root. The rationale for the limitation is described in a link that Michel shared [2]. In short, this option is reserved for "critical services" and should be used sparingly. But, as Steve said earlier, it is likely that the browser is the most important process to many desktop users. Maybe this limitation on setting ManagedOOMPreference could be removed, or eased to at least allow setting `ManagedOOMPreference=avoid` on non-root owned cgroups? For this to be effective, there would need to be other viable kill candidates (i.e. cgroups with greater than 5% swap usage) when the SwapUsedLimit is met. Thanks, Nick [1] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#ManagedOOMPreference=none%7Cavoid%7Comit [2] https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Can_we_exclude_certain_units_from_being_killed.3F -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: systemd-oomd issues on desktop
Am 14.06.22 um 01:22 schrieb Nick Rosbrook: On Mon, Jun 13, 2022 at 8:19 AM Lukas Märdian wrote: I wonder if we could use a more selective approach, though, using "OOMScoreAdjust=" in the systemd.exec environment (i.e. Gnome-Shell launcher in Ubuntu's context, as sd-oomd is currently only enabled on Ubuntu Desktop) [2], to reduce the probability of certain "important" apps being killed first, e.g. by maintaining an allow-list of such apps. IIUC, OOMScoreAdjust only influences the behavior of the kernel OOM killer, not systemd-oomd. In any case, I do agree that a "selective approach" might improve the current situation (this is what I tried to convey in option (2)). Indeed. I misread the man page "This setting also applies to systemd-oomd" => This only applies to "OOMPolicy=" and only as of v251 so it won't help us here. [1] The ManagedOOMPreference[1] option exists, but this property is ignored if the unit's cgroup is not owned by root. The rationale for the limitation is described in a link that Michel shared [2]. In short, this option is reserved for "critical services" and should be used sparingly. But, as Steve said earlier, it is likely that the browser is the most important process to many desktop users. Maybe this limitation on setting ManagedOOMPreference could be removed, or eased to at least allow setting `ManagedOOMPreference=avoid` on non-root owned cgroups? For this to be effective, there would need to be other viable kill candidates (i.e. cgroups with greater than 5% swap usage) when the SwapUsedLimit is met. Yes, I feel like allowing a "ManagedOOMPreference=avoid" for critical UI applications, would be a sensible change to make. This should allow starting applications like this (possibly integrated with the gnome-shell launcher for allow-listed applications): $ systemd-run --user -p ManagedOOMPreference=avoid firefox Should we setup a PPA to apply this modification for testing it against the "Do not enable swap kill at all" (option 3) approach and ask the affected users [2] to test both methods for the best outcome? Testing option (3) should be as easy as adding a new file in /etc to override the "ManagedOOMSwap=" setting, using the current systemd build available in Ubuntu Jammy: $ cat /etc/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf [Slice] ManagedOOMSwap=auto -- Lukas Thanks, Nick [1] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#ManagedOOMPreference=none%7Cavoid%7Comit [2] https://fedoraproject.org/wiki/Changes/EnableSystemdOomd#Can_we_exclude_certain_units_from_being_killed.3F [1] https://github.com/systemd/systemd/pull/22629 [2] https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
