On Friday, June 5, 2020 12:38:01 PM MST Igor Raits wrote: > On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr 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? 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. > > > Either you did not read the page or I misunderstand how zram works. It > will take 3G of your memory and call it a SWAP. With a compression. So > essentially, if the starts will be aligned you will end up with 9G of > memory. Of course, if that is not enough, you can add on top of that > swap on the disk. How in the world would I end up with 9G of memory? That's not how this tech works, at all. Compression doesn't magically mean you get 2x the amount of memory as you reserve for it. Compression rates even for plaintext aren't normally that high. -- John M. Harris, Jr. _______________________________________________ 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
