On Fri, Jun 5, 2020 at 1:18 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > > On Friday, June 5, 2020 12:12:40 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 1:07 PM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> > > wrote: > > > > > > > > > On Friday, June 5, 2020 11:48:14 AM MST Chris Murphy wrote: > > > > > > > On Fri, Jun 5, 2020 at 6:43 AM Michael Catanzaro <mcatanzaro@xxxxxxxxx> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 5, 2020 at 1:52 am, Chris Murphy > > > > > <lists@xxxxxxxxxxxxxxxxx> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > That is the plan, otherwise the swap-on-zram device probably never > > > > > > gets used. And then its overhead, which is small but not zero, is > > > > > > just > > > > > > a waste. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I thought the plan was to get rid of the disk-based swap partition, > > > > > since it has an unacceptable impact on system responsiveness? > > > > > > > > > > > > > > > > > > > > Default new installations, yes. No disk-based swap partition. > > > > > > > > > > > > > > > > For upgrades, there's no mechanism to remove an existing > > > > swap-on-drive. And the installer will still permit swap-on-drive being > > > > added in custom partitioning. Both of these paths results in two swap > > > > devices. > > > > > > > > > > > > > > > > We could ask Anaconda, if a custom installation creates swap-on-disk, > > > > to remove /etc/systemd/zram-generator.conf. And in that case, users > > > > will not get swap-on-zram. And we could also forgo the change being > > > > applied on upgrades. > > > > > > > > > > > > It may be best to respect the user's decision, and not add a zram device > > > on upgraded systems. This would lead to less unexpected behavior. I'd > > > support that, for sure :) > > > > > > Contra argument: It also leads to fragmentation of the user base. Most > > users use a distribution because they trust the decisions. And while > > it is only a preference, not a policy the Workstation Product > > Requirements Document says "Upgrading the system multiple times > > through the upgrade process should give a result that is the same as > > an original install of Fedora Workstation." > > > > There is a balancing act here that should be considered because a > > large percent of Fedora users upgrade rather than reprovision. It > > might even be the majority case. > > Well, that's for the GNOME stuff. This is a system-wide change proposal, is it > not? It is intended for all editions and spins. >Additionally, you could still be meeting that requirement here, as a new > install with the same options selected, that is, to have a swap partition, > would disable the zram device. That'd be a nice middleground for users like > myself that don't have enough RAM to waste on a zram device. I'm writing this > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where giving half of > my RAM to zram would kill my system's performance, if not quickly cause OOM. Ok so you've just decided to ignore that this is used already for years on ARM and Fedora IoT (including my 512M Raspberry Pi), and somehow you think your use case wouldn't benefit even though you haven't tried it? Maybe try it? You do not need to wait for F33. You can disable disk based swap and install the zram-generator right now on F31 or F32. Your use case is *exactly* what this feature has in mind. And it's even used by default in Chrome OS and Android when they moved to kernel 4.4, although not all OEM's opted in. By all means find a problem. Now is the perfect time for that. I am beginning to think this feature is like magic and I really want to see an edge case that blows up magnificently. In a year of testing I haven't found one that's worse than disk based swap. -- Chris Murphy _______________________________________________ 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
