-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 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. > -- > 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 - -- Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7anxkACgkQEV1auJxc Hh6kqg//a/iT6Cdeg9ZJrfuj/0xWerydUtwRwveG1GoUp6gHK92rDlADWreOpKtw p+aGbG/L01Mp4KrNJdwND4/5iy8F7/kB8DfBoEGVT7BNg2KRh/OQLmA5r0LVn6RE lEk+BbwDhHEsZoQQH5bicvMEMwO2J+kUL9edAH2ZW6ZQrsXilXIJxogUUuAoR9fH EaqadUaF5eWK3qf1HbMV5ffcraN6de+MYxA1C4peQoq5Dr8FPxjoZTl9ECtRMlpw 5utWnwwQZAQ9SDXyiIP1oJ3s+iR34eDwXr2V8Aq1940hoGbPsAOH1n6DNWkKULPq 6cnZE6tcCIu0bP3Gh7pmmtUZprK5yvIqdgGRXP+nImEXT0AevH3R/VTEsVQsL6f1 Qu4+MbsC5+hfHUj1JX9M2TDYztCtmcDO6q9P15dmG8KmemEeKZ4iAUsh3kZCq8p4 L9afY1quySpmnhpIFe68TjcIobclEOLSo9gtDbIgSvuPtVaPEXUpNqm/kP944CNv NGjLG8LJ+hWETbkji465ny6CSJS+vDj2LXu+Bv7ilhgjoV3PDwU0JGVSfSCEXb04 H8tl0KwSYH2QrOZZk89l5vlpjx2UEJwEQhXM/tHJAWDPRvyJSZdPVrBAlIBGSLpb hS4JJ5Em0ovA6jUK4kRHlm5xcuizrCfix/bCkp7MzIB0S4UkRbc= =kJR5 -----END PGP SIGNATURE----- _______________________________________________ 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
