Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, 28 Jul 2020 13:51:00 -0600 Chris Murphy wrote: > That information is stale. The feature page has been updated. > > man page contains: > >To disable a configuration file supplied by the vendor, the > recommended way is to place a symlink to /dev/null in the > configuration directory in /etc/, with the same filename as the vendor > configuration file. Thanks. > It's maybe easier to just 'dnf remove zram-generator-defaults' but > that is a Fedora specific instruction. After some thought, this is what I did after I posted the message. Makes sense, can't run if it isn't there. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Wed, Jul 29, 2020 at 12:56 AM John M. Harris Jr wrote: > > On Tuesday, July 28, 2020 12:51:00 PM MST Chris Murphy wrote: > > On Tue, Jul 28, 2020 at 11:29 AM stan via devel > > wrote: > > > > > > > > > > > On Thu, 4 Jun 2020 16:30:07 -0400 > > > Ben Cotton wrote: > > > > > > > > > > > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > > > > > > > > > > How can it be disabled? > > > > > > > > > > > > > > > > Immediately: > > > > swapoff /dev/zram0 > > > > > > > > > > > > > > > > Permanently: > > > > rm /etc/systemd/zram-generator.conf > > > > > > > > > > > > I realize this is a really late reply, but I wanted to disable this > > > since it was never used, and when I looked at the man pages this > > > information was not in them. I think it should be. > > > > > > That information is stale. The feature page has been updated. > > > > man page contains: > > > >To disable a configuration file supplied by the vendor, the > > recommended way is to place a symlink to /dev/null in the > > configuration directory in /etc/, with the same filename as the vendor > > configuration file. > > > > > > It's maybe easier to just 'dnf remove zram-generator-defaults' but > > that is a Fedora specific instruction. > > Well, that'll just make it come back on upgrade, wouldn't it? No. I've updated the Upgrade and Compatibility section to reflect how upgrades will work. It's quite a bit more narrow in scope than the original proposal. https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Upgrade.2Fcompatibility_impact -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
El lun., 6 jul. 2020 a las 18:15, Samuel Sieb () escribió: > On 7/6/20 1:48 PM, Sergio Belkin wrote: > > At > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F > > it says: > > > > "Do not create swap partition/LV with default installations." > > I don't understand if it is a description or a prescription :)I mean, > > can coexist swap partition/LV and zram? > > Yes, zram is just a compressed block device in RAM and it's being used > here as swap. You can have multiple swap devices active at the same > time. That's what I'm currently using. I have a zram swap device and a > disk swap partition as overflow. But the plan is to avoid having any > swap on disk by default. > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Thanks, event for the late answer :) For the record, I'm using zram as a swap device and I disabled the swap on disk. I have 16 GB of RAM and am using earlyoom on F32. There was only one several issue using a lot of apps and VirtualBox VM's. HTH -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tuesday, July 28, 2020 12:51:00 PM MST Chris Murphy wrote: > On Tue, Jul 28, 2020 at 11:29 AM stan via devel > wrote: > > > > > > > On Thu, 4 Jun 2020 16:30:07 -0400 > > Ben Cotton wrote: > > > > > > > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > > > > > > > How can it be disabled? > > > > > > > > > > > > Immediately: > > > swapoff /dev/zram0 > > > > > > > > > > > > Permanently: > > > rm /etc/systemd/zram-generator.conf > > > > > > > > I realize this is a really late reply, but I wanted to disable this > > since it was never used, and when I looked at the man pages this > > information was not in them. I think it should be. > > > That information is stale. The feature page has been updated. > > man page contains: > >To disable a configuration file supplied by the vendor, the > recommended way is to place a symlink to /dev/null in the > configuration directory in /etc/, with the same filename as the vendor > configuration file. > > > It's maybe easier to just 'dnf remove zram-generator-defaults' but > that is a Fedora specific instruction. Well, that'll just make it come back on upgrade, wouldn't it? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, Jul 28, 2020 at 11:29 AM stan via devel wrote: > > On Thu, 4 Jun 2020 16:30:07 -0400 > Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > > How can it be disabled? > > > > Immediately: > > swapoff /dev/zram0 > > > > Permanently: > > rm /etc/systemd/zram-generator.conf > > I realize this is a really late reply, but I wanted to disable this > since it was never used, and when I looked at the man pages this > information was not in them. I think it should be. That information is stale. The feature page has been updated. man page contains: To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file. It's maybe easier to just 'dnf remove zram-generator-defaults' but that is a Fedora specific instruction. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Thu, 4 Jun 2020 16:30:07 -0400 Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > How can it be disabled? > > Immediately: > swapoff /dev/zram0 > > Permanently: > rm /etc/systemd/zram-generator.conf I realize this is a really late reply, but I wanted to disable this since it was never used, and when I looked at the man pages this information was not in them. I think it should be. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 7/6/20 1:48 PM, Sergio Belkin wrote: At https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F it says: "Do not create swap partition/LV with default installations." I don't understand if it is a description or a prescription :)I mean, can coexist swap partition/LV and zram? Yes, zram is just a compressed block device in RAM and it's being used here as swap. You can have multiple swap devices active at the same time. That's what I'm currently using. I have a zram swap device and a disk swap partition as overflow. But the plan is to avoid having any swap on disk by default. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
El vie., 5 jun. 2020 a las 16:10, John M. Harris Jr () escribió: > On Friday, June 5, 2020 12:03:03 PM MST Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 11:47 AM John M. Harris Jr > > wrote: > > > > > > > > > On Thursday, June 4, 2020 11:54:37 PM MST Kevin Kofler wrote: > > > > > > > > > > Also -1 to adding something to the core system that is written in a > > > > language for which we do not even have dynamic linking support. Or > > > > even real static linking support, as opposed to packaging libraries > as > > > > source code.> > > > > > Kevin Kofler > > > > > > > > > > > > Agreed. Besides, GNOME already has this enabled, right? It's definitely > > > not right for servers, as I brought up the last time this was thrown > > > around. > > > > In discussions with both cloud and server folks, their use cases often > > do not even create disk-based swap at all. A small swap-on-zram > > provides all the benefits of inactive anonymous page eviction, > > including reducing reclaim of file pages, without the black hole > > performance problems of swap-on-drive. > > > > So yes it's well suited for these cases and the proposal does include > > them. If they wish to be left out, that's up to those working groups. > > It's possible to make sure /etc/systemd/zram-generator is not present. > > That doesn't seem to reflect reality. If you download the Server image > right > now, and go with its automatic partitioning scheme generation, it'll give > you > a swap partition on LVM. This is correct for most servers, not necessarily > the > LVM part, but having swap on disk. > > It really seems like this is wrong for most of Fedora, but that individual > parts, such as Fedora GNOME or IoT, should be left to make the decision > for > themselves, without affecting the rest. > > -- > John M. Harris, Jr. > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > At https://fedoraproject.org/wiki/Changes/SwapOnZRAM#Why_systemd_zram-generator.3F it says: "Do not create swap partition/LV with default installations." I don't understand if it is a description or a prescription :)I mean, can coexist swap partition/LV and zram? Thanks in advance! -- -- Sergio Belkin LPIC-2 Certified - http://www.lpi.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 30 June 2020 16:52:52 CEST, Matthew Miller wrote: >On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote: >> I have been using fedora since FC1 and there has been a few shifts. The >> latest shift seems to be a strong desire to be just another Ubuntu. That's >> fine, nothing wrong with that... Do we need more Ubuntus though? > >I don't know what it means to "be another Ubuntu". We're a different project >with a different structure and a different lineage. A distribution which has an aim to streamline the experience in order to cater to new users. Ubuntu is super good at this. > >Would I like the stuff we produce to be as popular as Ubuntu in terms of >user base? No -- I would like it to be more popular. And I think it's very >possible. I would like that too. > >I know change is hard. I used to be a grumpy sysadmin myself and I can >relate to a lot of what you're saying. But I don't think the "alienating >current users vs. attracting new users" dichotomy is a useful one. Many >current users will also benefit from and appreciate the proposed changes. Please don't go "change is hard" on me. That is what management do when they push for unpopular ideas. My problem isn't with change, my problem is with how the change is done and in some cases why the change is done. Change is not only inevitable it's also the only way things can get better. That doesn't mean that all changes are for the better. As for the "old users vs new users" not being useful, well, there's a few reasons why I'm still here. It's mainly that Fedora has good QA, SELinux and very current software. That suits me well for my home environment. What is pretty clear however, is that one can say "hold on how does this affect new users?" but "how does this affect current users?" isn't as interesting. I don't think the FOSS world needs another Ubuntu, Ubuntu already does that. I think Fedora can compete with that without giving up inclusiveness. There can be a Workstation edition that has sane defaults without hiding the fact that things can be configured. > >However, one size definitely does not fit all, and our strategy is designed >*precisely* to address that. Well ofc, but if there is going to be a new spin for every taste then the fragmentation will be a horrible. I'm a proponent of having a set of defaults and then having flexibility since that means people can coexist. But that also means that there needs to be flexibility in the install stage too. I used to be able just grab an ISO of getfedora in case of emergency and get a replacement machine up an running very quickly without much hassle because I could fix most things during the install stage. Now I have instead built kickstarts for the relevant machines and manage them via ansible. It's good sure but having to do it for my home environment is mildly annoying. So well, if I could find another distribution that is current, has good MAC and good QA I would probably use that. Problem is that it doesn't really exist and I like Fedora. I guess I'll just cover my own bases and mark workstation edition as Someone Elses Problem. > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Tue, Jun 30, 2020 at 08:43:34AM +0200, Markus Larsson wrote: > I have been using fedora since FC1 and there has been a few shifts. The > latest shift seems to be a strong desire to be just another Ubuntu. That's > fine, nothing wrong with that... Do we need more Ubuntus though? I don't know what it means to "be another Ubuntu". We're a different project with a different structure and a different lineage. Would I like the stuff we produce to be as popular as Ubuntu in terms of user base? No -- I would like it to be more popular. And I think it's very possible. I know change is hard. I used to be a grumpy sysadmin myself and I can relate to a lot of what you're saying. But I don't think the "alienating current users vs. attracting new users" dichotomy is a useful one. Many current users will also benefit from and appreciate the proposed changes. However, one size definitely does not fit all, and our strategy is designed *precisely* to address that. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Mon, Jun 29, 2020 at 06:29:09PM -0700, John M. Harris Jr wrote: > On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote: > > Hi > > > > On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > > > Thanks, I am well aware. That wasn't really the topic here. > > > > If there is a repeated feeling that anyone has that a particular edition > > isn't what they are looking for, figuring out how to make a different set > > of choices is and perhaps forming a community around their preferences is > > pertinent. This isn't addressed just to you. Having said that, what do > > you consider is the topic? > > The possibility of the start of the Grumpy Old Neckbeard Spin (actual name > TBD). Name it Fedora Devuan. Nb. amount of negative stop-energy you demonstrate is huge. Could you please try to be more productive and on-topic? -- Tomasz Torcz 72->| 80->| to...@pipebreaker.pl 72->| 80->| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 30 June 2020 02:04:18 CEST, Rahul Sundaram wrote: >Hi > >On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > >> >> Thanks, I am well aware. That wasn't really the topic here. >> > >If there is a repeated feeling that anyone has that a particular edition >isn't what they are looking for, figuring out how to make a different set >of choices is and perhaps forming a community around their preferences is >pertinent. This isn't addressed just to you. Having said that, what do >you consider is the topic? > >Rahul The topic at the moment was about how changes are made. It's also about highlighting that when a distribution goes all in on the hunt for new users one has to figure out if one wants to keep the old users. I have been using fedora since FC1 and there has been a few shifts. The latest shift seems to be a strong desire to be just another Ubuntu. That's fine, nothing wrong with that... Do we need more Ubuntus though? Regarding the language in the workstation target audience, well... I think it's narrow and that it shouldn't be. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote: > Hi > > On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > > Thanks, I am well aware. That wasn't really the topic here. > > If there is a repeated feeling that anyone has that a particular edition > isn't what they are looking for, figuring out how to make a different set > of choices is and perhaps forming a community around their preferences is > pertinent. This isn't addressed just to you. Having said that, what do > you consider is the topic? > > Rahul The possibility of the start of the Grumpy Old Neckbeard Spin (actual name TBD). -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
Hi On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote: > > Thanks, I am well aware. That wasn't really the topic here. > If there is a repeated feeling that anyone has that a particular edition isn't what they are looking for, figuring out how to make a different set of choices is and perhaps forming a community around their preferences is pertinent. This isn't addressed just to you. Having said that, what do you consider is the topic? Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 22:33:43 CEST, Rahul Sundaram wrote: >Hi > >On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson wrote: > >> >> No that doesn't help at all. It doesn't address what I wrote about many >> seeing a problem for the first time when a change is suggested and that >> this leads to more heated debates than needed. >> I also feel alienated by the target audience of Workstation since it >> pretty much only talks about developers and others. > > >It may very well be the case that workstation isn't what you are looking >for. If you want to create your own remix or spin, one quick way to field >this is to create a package in copr or have an ansible playbook that sets >the defaults and configuration you want and gathering some feedback on >whether others find it useful. > >Rahul Thanks, I am well aware. That wasn't really the topic here. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
Hi On Mon, Jun 29, 2020 at 4:30 PM Markus Larsson wrote: > > No that doesn't help at all. It doesn't address what I wrote about many > seeing a problem for the first time when a change is suggested and that > this leads to more heated debates than needed. > I also feel alienated by the target audience of Workstation since it > pretty much only talks about developers and others. It may very well be the case that workstation isn't what you are looking for. If you want to create your own remix or spin, one quick way to field this is to create a package in copr or have an ansible playbook that sets the defaults and configuration you want and gathering some feedback on whether others find it useful. Rahul ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 21:50:50 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 07:46:53PM +0200, Markus Larsson wrote: >> I think it would be beneficial to lift up the problems we're trying to >> solve and then work towards possible solutions. I don't think it even >> would take more time. I would probably help people commit to the problem >> and possibly accept the solution. It seems to me that many feel out of the >> loop and thus reacts stronger than needed. > >This is certainly one of the goals for the Editions strategy. Do > >* https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience >* https://fedoraproject.org/wiki/CoreOS/PRD#Target_Market_.2F_Audience >* >https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product_Objectives > >help? > > No that doesn't help at all. It doesn't address what I wrote about many seeing a problem for the first time when a change is suggested and that this leads to more heated debates than needed. I also feel alienated by the target audience of Workstation since it pretty much only talks about developers and others. I guess "you aren't part of the target audience" is a nicer than saying "take a hike neckbeard, this edition isn't even for you". I'm pretty sure that wasn't the intended message though but I can't figure out what the actual intended message was. Please help :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Mon, Jun 29, 2020 at 07:46:53PM +0200, Markus Larsson wrote: > I think it would be beneficial to lift up the problems we're trying to > solve and then work towards possible solutions. I don't think it even > would take more time. I would probably help people commit to the problem > and possibly accept the solution. It seems to me that many feel out of the > loop and thus reacts stronger than needed. This is certainly one of the goals for the Editions strategy. Do * https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience * https://fedoraproject.org/wiki/CoreOS/PRD#Target_Market_.2F_Audience * https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Product_Objectives help? -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 19:30:53 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 07:18:00PM +0200, Markus Larsson wrote: >> I think most of these things could be solved in better ways, I don't think >> the "change request"-route is a good way to get the discussion started >> though. It tends to become mudslinging matches where those who proposed >> the changes feel obligated to defend them and others become outraged. > >Yeah, I don't like that pattern either: that's actually why I'm suggesting >this. Rather than say no to other people, say yes to your own thing. I think it would be beneficial to lift up the problems we're trying to solve and then work towards possible solutions. I don't think it even would take more time. I would probably help people commit to the problem and possibly accept the solution. It seems to me that many feel out of the loop and thus reacts stronger than needed. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Mon, Jun 29, 2020 at 07:18:00PM +0200, Markus Larsson wrote: > I think most of these things could be solved in better ways, I don't think > the "change request"-route is a good way to get the discussion started > though. It tends to become mudslinging matches where those who proposed > the changes feel obligated to defend them and others become outraged. Yeah, I don't like that pattern either: that's actually why I'm suggesting this. Rather than say no to other people, say yes to your own thing. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On 29 June 2020 18:44:46 CEST, Matthew Miller wrote: >On Mon, Jun 29, 2020 at 06:30:11PM +0200, Markus Larsson wrote: >> A spin feels like a commitment that involves gathering what other people >> feel and need. While I'm cautious about some changes I tend to welcome >> change in general. I just need to see the benefits and there needs to be >> reason to expect it to be successful. > >That's true, and I'll admit there's a little bit of "show me the money" in >my stance here. The argument for these changes is based on the desire to >provide a better experience for an intended audience. But a number of people >in these threads are putting forth the assertation that there is a >meaningful number of users (including Fedora contributors) who would >actually be better served by a different set of defaults. Well, there are. But the main gripe, for me, is that year for year the defaults keep changing always catering to someone that is not me. Generally not because I'm changing but because things are deemed not welcoming enough. The Workstation installer is a prime example. I'm not saying it's bad just that I feel that a working tool was taken from me and was replaced by something that satisfies my needs to a much lesser extent. I too see the need for being welcoming, I just wish it could be less heavy handed. I also see a bit of arrogance towards new users, that they will break down crying if there things that can be configured (yes hyperbolic but hyperbole is here used to show the pattern, I'm not saying that people are actually arguing that users fall into tears if displayed options). I think most of these things could be solved in better ways, I don't think the "change request"-route is a good way to get the discussion started though. It tends to become mudslinging matches where those who proposed the changes feel obligated to defend them and others become outraged. > >If there enough people who believe that and want to work on it, it should be >easy to find a core group of maintainers, go through the Change process to >propose it, and find an enthusiastic user-base. And I don't mean this in a >snarky way: it seems reasonable enough to me that there's a sustainable >level of interest. If there is, great! If there isn't, well, we also learn >something. This and the btrfs stuff combined with earlier changes at least got me going on finally setting up an auto deployment solution for my home environment. I just wish I didn't have to. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]
On Mon, Jun 29, 2020 at 06:30:11PM +0200, Markus Larsson wrote: > A spin feels like a commitment that involves gathering what other people > feel and need. While I'm cautious about some changes I tend to welcome > change in general. I just need to see the benefits and there needs to be > reason to expect it to be successful. That's true, and I'll admit there's a little bit of "show me the money" in my stance here. The argument for these changes is based on the desire to provide a better experience for an intended audience. But a number of people in these threads are putting forth the assertation that there is a meaningful number of users (including Fedora contributors) who would actually be better served by a different set of defaults. If there enough people who believe that and want to work on it, it should be easy to find a core group of maintainers, go through the Change process to propose it, and find an enthusiastic user-base. And I don't mean this in a snarky way: it seems reasonable enough to me that there's a sustainable level of interest. If there is, great! If there isn't, well, we also learn something. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 29 June 2020 18:06:10 CEST, Matthew Miller wrote: >On Sat, Jun 27, 2020 at 10:09:08PM +0200, Markus Larsson wrote: >> I was thinking more in the lines of a Remix. >> Mainly to avoid spending time trying to get it blessed in the right >> forums. > >Sure, you could do that too. The process is to submit it as a Change to >FESCo just like this one, and since as I noted Fedora being able to provide >a variety of solutions catering to different users and use-cases is >literally in our mission, I don't think it should be particularly >controversial. People can disagree with what you're choosing for your spin, >but they don't have to use it. Just like you don't have to use nano. :) A spin feels like a commitment that involves gathering what other people feel and need. While I'm cautious about some changes I tend to welcome change in general. I just need to see the benefits and there needs to be reason to expect it to be successful. I have a feeling that a neckbeard purist spin would be to conservative for me and I don't want to invest work to get a spin approved and then land in a userbase of 1. With a remix though I'm totally fine with putting work in for that single person underbase :) > > >> If you think there room for a grumpy old neckbeard spin I'm sure I can >> find some time to contribute. > >I mean... you might want to workshop that name a little bit. :) Was it too honest? > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 27, 2020 at 10:09:08PM +0200, Markus Larsson wrote: > I was thinking more in the lines of a Remix. > Mainly to avoid spending time trying to get it blessed in the right > forums. Sure, you could do that too. The process is to submit it as a Change to FESCo just like this one, and since as I noted Fedora being able to provide a variety of solutions catering to different users and use-cases is literally in our mission, I don't think it should be particularly controversial. People can disagree with what you're choosing for your spin, but they don't have to use it. Just like you don't have to use nano. :) > If you think there room for a grumpy old neckbeard spin I'm sure I can > find some time to contribute. I mean... you might want to workshop that name a little bit. :) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 28, 2020 at 10:47:14PM -0400, Matthew Miller wrote: > The Council talked about this at our meeting in Minneapolis in 2018. We > didn't ask FESCo to update the technical policy to reflect the strategic > plan... but probably we should. https://pagure.io/fesco/issue/2418 (Includes links to the Council policies too for reference.) -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Monday, June 29, 2020 12:58:30 AM MST Zbigniew Jędrzejewski-Szmek wrote: > On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote: *snip* > > - Mask/disable systemd-homed > > > Doesn't do anything unless you create some users with homectl. There's no reason for it to be there, wasting resources. > > - Mask/disable systemd-userdb > > > That's just a proxy service to provide user records as json. On its > own it doesn't really do much. That's awful, and the above applies there as well. > > - Mask/disable systemd-sysusers > > > Well, various packages make use of systemd-sysusers so if you disable > systemd-sysusers, they won't get a user created and will likely not > work. Also doesn't do anything if there's no configuration. But knock > yourself out. I don't think that's the case, since that Change required that `useradd` (or was it `adduser`?) be used. It'd be worth a try to remove the systemd bloat. > > - Mask/disable systemd-repart > > > Doesn't do anything unless you provide a configuration file. So it has no reason to be there. > > - Mask/disable systemd-resolved > > > That's trivially disabled. The Change page lists a few mechanisms. It's one of the many things in this list. Each one may be "trivially disabled", but it all adds up. > > - Mask/disable systemd-networkd > > > Doesn't do anything unless you provide configuration files. And, so, it shouldn't be there, wasting resources. > > - Mask/disable systemd-timesyncd > > > Chrony is the default choice in Fedora, so until you uninstall chrony > and enable timesyncd, you're safe. Same as above, it's unnecessary bloat. > > - Disable systemd-xdg-autostart-generator > > > That's a mechanism for gnome and kde to spawn apps. Right now it's not > used yet, but it might in the future... I guess your best bet is not > to use gnome or kde. TWM would be a safe choice ;) systemd has no place doing the DE's job. That's why I have a DE, instead of systemdOS. :) > > - Remove the privacy anti-feature of using Google DNS when none are > > configured > > In general people seem to prefer to have a functional network without > manual configuration. So we want to pick *some* default. Google DNS > seems to be not better or worse than other major providers. But if > you'd rather prefer to have no DNS if none is configured, it's still a > one line config to "fix" the issue. Generally, if there are no configured servers, people expect that.. there are no DNS servers in use. That's how it should be. I don't expect the system to outright subvert my intentions to run off to Google, and I'm sure others don't either. See the systemd-resolved Change "proposal" thread for more information on that. > > - Disable fstrim.timer > > - Disable EarlyOOM > > - Not set a default EDITOR > > > All those are trivially done with a single command or one-line file. That'd be the purpose of the Spin, so that users don't have to keep track of all of the things that need to be fixed. > > - Have no modular repos by default > > > This one will soon be trivially done with a single command. Yes, and that'll make it all the more simple to add it as an excluded package in the Spin's kickstart! ;) > > - Not use btrfs or XFS as the default filesystem > > > Pick a different default when installing... Hey, that's my line! Seriously though, that wasn't really a fair thing for me to write. At the time, I was of the attitude of "I don't really care if it breaks users' systems", and to "let those folks make a mockery of Fedora with that default". Sure, folks who are in the know will pick their own partitioning scheme and filesystems of choice. However, that doesn't solve the UX of a new user. > > From this list, I know it might look like I'm calling out systemd. Well, > > that's just because it's become so bloated. > > > I'd say "useful", but that's just words. Anyway, each of the items on > this list can be easily disabled. I guess you could provide a simple rpm > in a copr repo somewhere that does this. I don't see why it'd need to be copr, I actually like mattdm's suggestion above. Some of these may need a bit more consideration, such as sysusers, but it'd have a lot of value to Fedora users. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 28, 2020 at 01:32:41PM -0700, John M. Harris Jr wrote: > On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote: > > > > > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > > > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > > > is really getting out of hand. > > > > > > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > > > there are at least of few of y'all who feel strongly about some of these > > > defaults. I encourage you to make a spin that caters to that experience. > > > > > > I'm a fan of spins too, but making a spin to do > > 'touch /etc/systemd/zram-generator.conf' seems a bit much. > > Far from just that: > > - Mask/disable systemd-homed Doesn't do anything unless you create some users with homectl. > - Mask/disable systemd-userdb That's just a proxy service to provide user records as json. On its own it doesn't really do much. > - Mask/disable systemd-sysusers Well, various packages make use of systemd-sysusers so if you disable systemd-sysusers, they won't get a user created and will likely not work. Also doesn't do anything if there's no configuration. But knock yourself out. > - Mask/disable systemd-repart Doesn't do anything unless you provide a configuration file. > - Mask/disable systemd-resolved That's trivially disabled. The Change page lists a few mechanisms. > - Mask/disable systemd-networkd Doesn't do anything unless you provide configuration files. > - Mask/disable systemd-timesyncd Chrony is the default choice in Fedora, so until you uninstall chrony and enable timesyncd, you're safe. > - Disable systemd-xdg-autostart-generator That's a mechanism for gnome and kde to spawn apps. Right now it's not used yet, but it might in the future... I guess your best bet is not to use gnome or kde. TWM would be a safe choice ;) > - Remove the privacy anti-feature of using Google DNS when none are configured In general people seem to prefer to have a functional network without manual configuration. So we want to pick *some* default. Google DNS seems to be not better or worse than other major providers. But if you'd rather prefer to have no DNS if none is configured, it's still a one line config to "fix" the issue. > - Disable fstrim.timer > - Disable EarlyOOM > - Not set a default EDITOR All those are trivially done with a single command or one-line file. > - Have no modular repos by default This one will soon be trivially done with a single command. > - Not use btrfs or XFS as the default filesystem Pick a different default when installing... > From this list, I know it might look like I'm calling out systemd. Well, > that's just because it's become so bloated. I'd say "useful", but that's just words. Anyway, each of the items on this list can be easily disabled. I guess you could provide a simple rpm in a copr repo somewhere that does this. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 28, 2020 at 07:28:34PM +0100, Peter Robinson wrote: > Technically yes, see the fedora-release-* for one of the Editions, all > the spins should have the equivalent now, not sure if there's a FESCo > policy on it though. The Council talked about this at our meeting in Minneapolis in 2018. We didn't ask FESCo to update the technical policy to reflect the strategic plan... but probably we should. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sunday, June 28, 2020 12:18:32 PM MST Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote: > > > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > > is really getting out of hand. > > > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > > there are at least of few of y'all who feel strongly about some of these > > defaults. I encourage you to make a spin that caters to that experience. > > > I'm a fan of spins too, but making a spin to do > 'touch /etc/systemd/zram-generator.conf' seems a bit much. Far from just that: - Mask/disable systemd-homed - Mask/disable systemd-userdb - Mask/disable systemd-sysusers - Mask/disable systemd-repart - Mask/disable systemd-resolved - Mask/disable systemd-networkd - Mask/disable systemd-timesyncd - Disable systemd-xdg-autostart-generator - Remove the privacy anti-feature of using Google DNS when none are configured - Disable fstrim.timer - Disable EarlyOOM - Not set a default EDITOR - Not use btrfs or XFS as the default filesystem - Have no modular repos by default From this list, I know it might look like I'm calling out systemd. Well, that's just because it's become so bloated. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 27, 2020 at 03:34:17PM -0400, Matthew Miller wrote: > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > Jesus Christ, this actually got approved. It's time to fork Fedora. This is > > really getting out of hand. > > As mentioned earlier, there's no need to "fork Fedora". It sounds like there > are at least of few of y'all who feel strongly about some of these defaults. > I encourage you to make a spin that caters to that experience. I'm a fan of spins too, but making a spin to do 'touch /etc/systemd/zram-generator.conf' seems a bit much. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
> On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote: > > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > > is really getting out of hand. > > > > > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > > there are at least of few of y'all who feel strongly about some of these > > defaults. I encourage you to make a spin that caters to that experience. > > Whoops, I forgot we can have spins with different defaults from the entire > distro now. That wasn't the case last time I looked into that, and I was going > to create a Remix. Technically yes, see the fedora-release-* for one of the Editions, all the spins should have the equivalent now, not sure if there's a FESCo policy on it though. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Saturday, June 27, 2020 12:34:17 PM MST Matthew Miller wrote: > On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > > > Jesus Christ, this actually got approved. It's time to fork Fedora. This > > is really getting out of hand. > > > > As mentioned earlier, there's no need to "fork Fedora". It sounds like > there are at least of few of y'all who feel strongly about some of these > defaults. I encourage you to make a spin that caters to that experience. Whoops, I forgot we can have spins with different defaults from the entire distro now. That wasn't the case last time I looked into that, and I was going to create a Remix. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 27 June 2020 21:34:17 CEST, Matthew Miller wrote: >On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: >> Jesus Christ, this actually got approved. It's time to fork Fedora. This is >> really getting out of hand. > > >As mentioned earlier, there's no need to "fork Fedora". It sounds like there >are at least of few of y'all who feel strongly about some of these defaults. >I encourage you to make a spin that caters to that experience. > I was thinking more in the lines of a Remix. Mainly to avoid spending time trying to get it blessed in the right forums. If you think there room for a grumpy old neckbeard spin I'm sure I can find some time to contribute. /M ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 27, 2020 at 10:25:01AM -0700, John M. Harris Jr wrote: > Jesus Christ, this actually got approved. It's time to fork Fedora. This is > really getting out of hand. As mentioned earlier, there's no need to "fork Fedora". It sounds like there are at least of few of y'all who feel strongly about some of these defaults. I encourage you to make a spin that caters to that experience. -- Matthew Miller Fedora Project Leader ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 27, 2020 at 11:25 AM John M. Harris Jr wrote: > Jesus Christ, this actually got approved. It's time to fork Fedora. This is > really getting out of hand. It will not apply to upgrades, just new clean installs. Still pending discussion with installer team on whether to also use it by default when users custom partition and manually add a swap partition (and test day). Maybe circle back on the upgrades question (and others about zswap) for Fedora 34. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Thursday, June 4, 2020 1:30:07 PM MST Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/SwapOnZRAM > > == Summary == > > Swap is useful, except when it's slow. zram is a RAM drive that uses > compression. Create a swap-on-zram during start-up. And no longer use > swap partitions by default. > > > == Owner == > * Name: [[User:chrismurphy| Chris Murphy]] > * Email: chrismur...@fedoraproject.org > > == Detailed Description == > > zram Basic function > > The zram† device, typically /dev/zram0, > has a size set at create time during early boot, by zram-generator† > per its configuration file. The memory used is not preallocated. It's > dynamically allocated and deallocated, on demand. Due to compression, > a full /dev/zram0 uses half as much > memory as its size. > > The /dev/zram0 behaves like any other > block device. It can be formatted with a file system, or mkswap, which > is the intention with this change proposal. > > The system will use RAM normally up until it's full, and then start > paging out to swap-on-zram, same as a conventional swap-on-drive. The > zram driver starts to allocate memory at roughly 1/2 the rate of page > outs, due to compression. But, there is no free lunch. This means > swap-on-zram is not as effective at page eviction as swap-on-drive, > the eviction rate is ~50% instead of 100%. But it is at least an order > of magnitude faster than drive based swap. > > zram has about 0.1% overhead or ~1MiB/1GiB. If the workload never > touches swap, this overhead is the sole cost. In practice when not > used at all, feature owner has experienced ~0.04% overhead. > > Example: A system has 16 GiB RAM. The proposed defaults suggest the > /dev/zram0 device will be 4 GiB. If the > workload completely fills up swap with 4 GiB of anonymous pages, > what's happened? The zramctl command will > display the true compression ratio. If 2:1 is really obtained, it > means 4GiB swap data is compressed to 2GiB. Therefore 2GiB is the > actual RAM usage, and is also the net effective eviction. i.e. 4 GiB > anonymous pages are evicted, but are then compressed and pinned into 2 > GiB RAM, for a net memory savings of 2 GiB. > > † > [https://www.kernel.org/doc/Documentation/blockdev/zram.txt kernel.org > zram.txt] > [https://github.com/systemd/zram-generator Github zram-generator project] > > > Overview of the Feature > > Using swap is a good idea†, but no one likes it when it's slow. > Anaconda and Fedora IoT have been using swap-on-zram by default for > years. This builds on their prior effort. > > > There are three components to the change: > > # Install systemd rust-zram-generator† package. This does not enable > swap-on-zram, it only makes the generator available. > # Install a default zram-generator configuration. When present, > swap-on-zram is set-up during startup. > # Do not create swap partition/LV with default installations. > > This proposal aims to apply all three, for all Fedora editions and > spins, by default. > > It further aims to apply the first two, for upgrades and custom > installations. > It might be useful to only make the generator available (1), should an > edition/spin wish to opt out, or as a fallback if applying the feature > to upgrades fails to withstand scrutiny. > > † > There is a tl;dr section at the top. Highly recommend reading the > whole article. [https://chrisdown.name/2018/01/02/in-defence-of-swap.html > In defence of swap: common misconceptions] > > > Default zram device configuration: > > During startup, create a zram device style=color:brown>/dev/zram0, with a size equal to 50% RAM, but > capped† to 4 GiB, and with a higher than typical swap priority†. > > These values seem reasonably conservative, and are based on prior work > in Fedora. Anaconda sets swap-on-drive sized to 50% RAM in the no > hibernation case, common outside x86. Fedora IoT's implementation also > sets swap-on-zram size to 50% RAM. > > † > [https://github.com/systemd/zram-generator/issues/10 RFE: should be > able to set a cap on zram device size #10] > > [https://github.com/systemd/zram-generator/issues/8 RFE: should set priority > #8] > > Default installer behavior > > The installer is currently responsible for creating a swap-on-drive > device. This will be dropped. The zram-generator + configuration file > will trigger the setup and activation of swap-on-zram. This means > hibernation isn't possible, even on systems that could support it. > > Please see > [https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md > Supporting hibernation in Workstation edition] for much more detailed > information, including why it's increasingly likely hibernation isn't > possible anyway, and a path to improving hibernation support. > > > Custom/Advance partitioning installer behavior > > The user can add swap using Custom partitioning at install time. This > is swap-on-drive. And the installer will
Re: Fedora 33 System-Wide Change proposal: swap on zram
Help needed! We're discussing the parameters of the test day, and the difficulty is answering: "what are the test cases?" This comment and the one after it: https://pagure.io/fedora-qa/issue/632#comment-658340 What language simply and properly conveys that the "test case" is essentially created on-the-fly by the user, based on their expectation of a particular workload they know stresses their system? We aren't looking for test cases that would blow up the system whether it's using disk-based or zram-based swap. We want to discover cases where things work with disk-based swap, but not zram-based swap. A generic description might be: a workload that you perform that results in OOM 50% of the time. OK now try that workload using swap-on-zram, does it succeed or fail more often than 50% of the time? Thanks! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Wednesday, June 10, 2020 2:50:55 AM MST Kevin Kofler wrote:
> John M. Harris Jr wrote:
>
> > What's even more wild is that you can't easily disable it. Even though
> > it's supposed to be disabled ("vendor preset: disabled") it's actually
> > built into systemd, as a static unit.
>
>
> Have you tried masking the units? Disabling tends to have only limited
> success (because it only disables the unit loading by itself, but not it
> getting loaded by other units), masking is more effective.
I'm aware, and I have had success with masking the ones I've had issues with
so far.
--
John M. Harris, Jr.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
John M. Harris Jr wrote:
> What's even more wild is that you can't easily disable it. Even though
> it's supposed to be disabled ("vendor preset: disabled") it's actually
> built into systemd, as a static unit.
Have you tried masking the units? Disabling tends to have only limited
success (because it only disables the unit loading by itself, but not it
getting loaded by other units), masking is more effective.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tuesday, June 9, 2020 2:24:02 AM MST Kevin Kofler wrote:
> John M. Harris Jr wrote:
>
> > I wonder if we could get that masked in Fedora Server and KDE Spin,
> > potentially along with homed, userdb, repart (Who in the world thought
> > this was a good idea?), resolved, networkd,
> > systemd-xdg-autostart-generator (you've got to be kidding with these
> > generators.. that's the DE's job, not the init system), systemd-sysusers,
> > systemd-growfs, and an ever growing list of absurd things thrown into an
> > init system.
>
>
> Are all those things enabled in Fedora by default? repart and growfs sound
> particularly scary to me. How do they even decide what partitions they want
> to create or grow? I definitely do not want systemd to mess with my
> partitions, even if it does not delete anything!
>
>
> > These things are not discoverable at all. This stuff really needs to stop
> > trying to guess what the user/sysadmin wants to do.
>
>
> Yes, I think this is going too far lately. I think the first generation of
> systemd modules, where the main idea was replacing ugly shell scripts with
> fast native C code, was a good idea, and systemd initially actually made
> things easier to configure (so I have never understood those systemd
> haters), but these days, the feature creep is adding complexity instead of
> removing it.
I completely agree. For example, I really like systemd as it is in RHEL7. Past
that, it's an ever growing list of things that have nothing to do with the
init system. Instead of being a fairly elegant init system, it's got more and
more cruft thrown in on top.
Contrary to what is repeatedly claimed, these do still run even if there's no
config, even if they don't do anything, which isn't the case. systemd-homed
was mounting /home where it was explicitly listed as `noauto` last time I
checked. See the output of `systemctl status systemd-homed` or `systemctl
status systemd-repart`. What's even more wild is that you can't easily disable
it. Even though it's supposed to be disabled ("vendor preset: disabled") it's
actually built into systemd, as a static unit.
To quote Lennart on one of these, userdb specifically, "not sure I get this?
why disable this at all? it's a tiny daemon, and shouldn't matter at all..."
> This reminds me more and more of that proprietary operating system which
> does lots of complex and controversial things without asking you and where
> you have to hunt down obscure registry keys in an attempt to hopefully stop
> it from doing those things.
Agreed on this as well, and that's making life hell for sysadmins and users
alike.
--
John M. Harris, Jr.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, 2020-06-09 at 09:04 -0600, Chris Murphy wrote: > On Mon, Jun 8, 2020 at 4:54 PM Konstantin Kharlamov < > hi-an...@yandex.ru> wrote: > > > So, I am testing ZRAM right now (as per your advice in another > > thread). All well > > so far, however reading this makes me think I gonna stumble upon a > > point where > > ZSRAM will be a better fit. > > > > You see, the idea of ZRAM and ZSWAP is improving low-memory > > situation. This is > > especially relevant for small amount of RAM, like your Raspberry > > example. > > > > In such situation if you, for example, open a lot of tabs in a > > browser, you may > > easily get to a point where even ZRAM is exhausted. Now, had you > > additionally a > > SWAP device, it would be no problem, the data would simply spill > > over to SWAP. > > > > Yes, SWAP is slow (well, it is on HDD at least). But consider this: > > in this > > workload , you most likely not gonna touch older of browser tabs > > for quite some > > time, so the slowness won't hurt you. > > SD Cards are pretty slow in Pi's. And also they have much more > limited > wear endurance than laptop SSDs. So in this use case for sure, memory > based swap only is idea. If it's not enough, then I think I've > reached > the physical limits of the configuration. But how to make this more > dynamic and smarter is certainly an area worth exploration, including > the idea of creating swapfiles on demand. But that is beyond the > scope > of this feature change. > > > > Now, I love the idea of using either ZRAM or ZSWAP. But to consider > > which one of > > them do we want, I think we would need to discuss first: do we > > really want to get > > rid of disk swap? Hibernation being discussed somewhere in this > > thread is another > > point. I personally don't like idea of removing disk swap. > > It is worth continuing the discussion. But for non-hibernation and > incidental swap, taking up more than 4G of swap seems excessive and > only leads to slow systems that will never OOM until all of the swap > partition is full. Btw, how about a compromise: we could use ZRAM for installations without SWAP partition and ZSRAM in case user decided to add a SWAP partition? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, Jun 9, 2020 at 3:44 AM Marius Schwarz wrote: > > And ZRAM is one of the tools, that should not be enabled by default > anyway. In a best case scenario it extends memory, but in most cases it > slows it down. With 16GB there isn't even a use-case for it. > I don't think that can be said as absolute. While I have 16GB in my desktop workstation and pretty much build packages from source and rarely use any swap, there was one package I couldn't build because of extensive use of c++ templating. There's no guarantee that having zswap/zram would have made it possible, but it might have. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/9/20 1:43 AM, Marius Schwarz wrote: And ZRAM is one of the tools, that should not be enabled by default anyway. In a best case scenario it extends memory, but in most cases it slows it down. With 16GB there isn't even a use-case for it. It doesn't slow anything down. If you don't use it, it's only taking up a few KB of RAM. If you do end up needing it, it's there and it saves you from slow disk swapping. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Mon, Jun 8, 2020 at 4:54 PM Konstantin Kharlamov wrote: > So, I am testing ZRAM right now (as per your advice in another thread). All > well > so far, however reading this makes me think I gonna stumble upon a point where > ZSRAM will be a better fit. > > You see, the idea of ZRAM and ZSWAP is improving low-memory situation. This is > especially relevant for small amount of RAM, like your Raspberry example. > > In such situation if you, for example, open a lot of tabs in a browser, you > may > easily get to a point where even ZRAM is exhausted. Now, had you additionally > a > SWAP device, it would be no problem, the data would simply spill over to SWAP. > > Yes, SWAP is slow (well, it is on HDD at least). But consider this: in this > workload , you most likely not gonna touch older of browser tabs for quite > some > time, so the slowness won't hurt you. SD Cards are pretty slow in Pi's. And also they have much more limited wear endurance than laptop SSDs. So in this use case for sure, memory based swap only is idea. If it's not enough, then I think I've reached the physical limits of the configuration. But how to make this more dynamic and smarter is certainly an area worth exploration, including the idea of creating swapfiles on demand. But that is beyond the scope of this feature change. > Now, I love the idea of using either ZRAM or ZSWAP. But to consider which one > of > them do we want, I think we would need to discuss first: do we really want to > get > rid of disk swap? Hibernation being discussed somewhere in this thread is > another > point. I personally don't like idea of removing disk swap. It is worth continuing the discussion. But for non-hibernation and incidental swap, taking up more than 4G of swap seems excessive and only leads to slow systems that will never OOM until all of the swap partition is full. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Mon, Jun 8, 2020 at 4:32 PM Konstantin Kharlamov wrote: > > Well, recent articles on LWN mention a spike in interest to hibernation¹, so > I'd expect hibernation to get improved. It's a start. They may also want to pick up the encrypted+signed work, but for different reasons. In the cloud case, they intentionally want to resume to a VM that is not the same as the origin. > And I'm not sure it's fair to rule out hibernation forever because of > existing problems on some hw setups. Windows 10 has by default a thing called > "fast startup" which is AFAIK simply hibernation. If that works for them, I > guess we can make it too? My research suggests they have similar problems with ACPI bugs related to S4; what I don't know is if they have make/model specific work arounds that improve the reliability. Also, they are more focused on S0 low power idle, i.e. Modern Standby. Far fewer bugs. There is some work happening in this area in the linux kernel. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Di, 09.06.20 11:24, Kevin Kofler (kevin.kof...@chello.at) wrote: > John M. Harris Jr wrote: > > I wonder if we could get that masked in Fedora Server and KDE Spin, > > potentially along with homed, userdb, repart (Who in the world thought > > this was a good idea?), resolved, networkd, > > systemd-xdg-autostart-generator (you've got to be kidding with these > > generators.. that's the DE's job, not the init system), systemd-sysusers, > > systemd-growfs, and an ever growing list of absurd things thrown into an > > init system. > > Are all those things enabled in Fedora by default? repart and growfs sound > particularly scary to me. How do they even decide what partitions they want > to create or grow? I definitely do not want systemd to mess with my > partitions, even if it does not delete anything! Here's a novel idea: maybe read up on it, before making such a fuss about it. You are fud'ing, and you know it. Hint: they are NOPs if there's no configuration for them. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, Jun 9, 2020 at 5:25 AM Kevin Kofler wrote: > > John M. Harris Jr wrote: > > I wonder if we could get that masked in Fedora Server and KDE Spin, > > potentially along with homed, userdb, repart (Who in the world thought > > this was a good idea?), resolved, networkd, > > systemd-xdg-autostart-generator (you've got to be kidding with these > > generators.. that's the DE's job, not the init system), systemd-sysusers, > > systemd-growfs, and an ever growing list of absurd things thrown into an > > init system. > > Are all those things enabled in Fedora by default? repart and growfs sound > particularly scary to me. How do they even decide what partitions they want > to create or grow? I definitely do not want systemd to mess with my > partitions, even if it does not delete anything! > These modules are used specifically for cloud variants so that on first boot, we can reconfigure VM images to match the storage setup requested with cloud-init/ignition. We don't use repart or growfs in Server Edition or desktop variants. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
John M. Harris Jr wrote: > I wonder if we could get that masked in Fedora Server and KDE Spin, > potentially along with homed, userdb, repart (Who in the world thought > this was a good idea?), resolved, networkd, > systemd-xdg-autostart-generator (you've got to be kidding with these > generators.. that's the DE's job, not the init system), systemd-sysusers, > systemd-growfs, and an ever growing list of absurd things thrown into an > init system. Are all those things enabled in Fedora by default? repart and growfs sound particularly scary to me. How do they even decide what partitions they want to create or grow? I definitely do not want systemd to mess with my partitions, even if it does not delete anything! > These things are not discoverable at all. This stuff really needs to stop > trying to guess what the user/sysadmin wants to do. Yes, I think this is going too far lately. I think the first generation of systemd modules, where the main idea was replacing ugly shell scripts with fast native C code, was a good idea, and systemd initially actually made things easier to configure (so I have never understood those systemd haters), but these days, the feature creep is adding complexity instead of removing it. This reminds me more and more of that proprietary operating system which does lots of complex and controversial things without asking you and where you have to hunt down obscure registry keys in an attempt to hopefully stop it from doing those things. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Am 09.06.20 um 02:03 schrieb Kevin Kofler: > I disagree. /etc should be prepopulated by packages and/or the distribution > installer. Then the directory is left for the local admin to customize. Not to speak of the fact, that you do not know which defaults are in place, if they are not visible somewhere logical placed. And even with systemds default in a config, we had a very stupid situation where limits have been in place, that were commented OUT in the default config, but systemd did set them because they were hardcoded in it. A sane hardcoded default in case /etc broke somehow is fine, but only as a last resort to boot up a working system to fix itself. And ZRAM is one of the tools, that should not be enabled by default anyway. In a best case scenario it extends memory, but in most cases it slows it down. With 16GB there isn't even a use-case for it. best regards, Marius ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Tue, Jun 9, 2020 at 12:21 AM John M. Harris Jr wrote: > > On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote: > > Lennart Poettering wrote: > > > > > Well, if you don#t want that behaviour don't use the partition type > > > UUIDs from the "discoverable partition spec" for your partitions. > > > > > > It's how these type uuids are defined: > > > > > > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > > > > > By using these partition type uuids you basically say: "please > > > automatically mount me, thank you". > > > > > > Uh, no. Any tools that create a partition table will use that UUID if I > > create a swap partition. That's all that UUID really means: "this is a > > GNU/Linux swap partition". You unilaterally redefined it to mean that the > > partition should be automatically mounted even if I deliberately keep it > > commented out in /etc/fstab. That conflicts with the original definition of > > that UUID, which is followed by all the partitioning tools out there. > > I have had the systemd-auto-gpt-generator masked on all my systems for years > > (ever since I found out about its existence), and it will remain that > > way, sorry. > > > > I was really angry back when I looked at the KSensors statistics, noticed > > that the swap space was twice as large as expected, and realized that > > systemd has decided to mount my spare swap partition on my SSD behind my > > back and hence been using up my SSD behind my back for months. Thankfully, > > the SSD still works years later, looks like I caught it early enough. (You > > can be glad that you have that warranty disclaimer in the license, in any > > case…) Ever since, systemd-auto-gpt-generator is masked. > > I wonder if we could get that masked in Fedora Server and KDE Spin, > potentially along with homed, userdb, repart (Who in the world thought this > was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've > got to be kidding with these generators.. that's the DE's job, not the init > system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd > things thrown into an init system. > > These things are not discoverable at all. This stuff really needs to stop > trying to guess what the user/sysadmin wants to do. > What makes you think the stuff we had before was discoverable? I can tell you right now that it definitely wasn't. These newer things have the advantage of coherent documentation, unified interfaces, and consistent availability across distributions. The amount of effort to discover and leverage this functionality is dramatically lower than what it was a decade ago with the older things. It's a lot easier to not accidentally break things, too! I would not support rolling back all this functionality, and I personally heavily use all of this across my servers and desktops. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Monday, June 8, 2020 5:03:20 PM MST Kevin Kofler wrote: > Lennart Poettering wrote: > > > Well, if you don#t want that behaviour don't use the partition type > > UUIDs from the "discoverable partition spec" for your partitions. > > > > It's how these type uuids are defined: > > > > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > > > By using these partition type uuids you basically say: "please > > automatically mount me, thank you". > > > Uh, no. Any tools that create a partition table will use that UUID if I > create a swap partition. That's all that UUID really means: "this is a > GNU/Linux swap partition". You unilaterally redefined it to mean that the > partition should be automatically mounted even if I deliberately keep it > commented out in /etc/fstab. That conflicts with the original definition of > that UUID, which is followed by all the partitioning tools out there. > I have had the systemd-auto-gpt-generator masked on all my systems for years > (ever since I found out about its existence), and it will remain that > way, sorry. > > I was really angry back when I looked at the KSensors statistics, noticed > that the swap space was twice as large as expected, and realized that > systemd has decided to mount my spare swap partition on my SSD behind my > back and hence been using up my SSD behind my back for months. Thankfully, > the SSD still works years later, looks like I caught it early enough. (You > can be glad that you have that warranty disclaimer in the license, in any > case…) Ever since, systemd-auto-gpt-generator is masked. I wonder if we could get that masked in Fedora Server and KDE Spin, potentially along with homed, userdb, repart (Who in the world thought this was a good idea?), resolved, networkd, systemd-xdg-autostart-generator (you've got to be kidding with these generators.. that's the DE's job, not the init system), systemd-sysusers, systemd-growfs, and an ever growing list of absurd things thrown into an init system. These things are not discoverable at all. This stuff really needs to stop trying to guess what the user/sysadmin wants to do. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Lennart Poettering wrote: > Well, if you don#t want that behaviour don't use the partition type > UUIDs from the "discoverable partition spec" for your partitions. > > It's how these type uuids are defined: > > https://systemd.io/DISCOVERABLE_PARTITIONS/ > > By using these partition type uuids you basically say: "please > automatically mount me, thank you". Uh, no. Any tools that create a partition table will use that UUID if I create a swap partition. That's all that UUID really means: "this is a GNU/Linux swap partition". You unilaterally redefined it to mean that the partition should be automatically mounted even if I deliberately keep it commented out in /etc/fstab. That conflicts with the original definition of that UUID, which is followed by all the partitioning tools out there. I have had the systemd-auto-gpt-generator masked on all my systems for years (ever since I found out about its existence), and it will remain that way, sorry. I was really angry back when I looked at the KSensors statistics, noticed that the swap space was twice as large as expected, and realized that systemd has decided to mount my spare swap partition on my SSD behind my back and hence been using up my SSD behind my back for months. Thankfully, the SSD still works years later, looks like I caught it early enough. (You can be glad that you have that warranty disclaimer in the license, in any case…) Ever since, systemd-auto-gpt-generator is masked. IMHO, something that mounts partitions behind my back should not exist to begin with. > I am sorry, but in this day and age I am sure we should default to > stuff that just works, and that means: defaults should apply with > empty or immutable /etc. > > By making this a default but list it in a configuration file to work, > you require /etc to be writable or populated, and that just sucks. I disagree. /etc should be prepopulated by packages and/or the distribution installer. Then the directory is left for the local admin to customize. It makes no sense whatsoever for /etc to be immutable. Being writable is part of the definition of /etc. > I disagree. We should strive for a system that works with empty /etc/ > and if booted that way uses default settings. That is just not going to happen, globally. A lot of applications ship default settings in /etc that are not contained in the code, or even differ from the hardcoded fallback defaults in the code (also because the Fedora defaults may differ from the upstream defaults for various reasons). It is perfectly valid for a package to install %config or %config(noreplace) files to /etc, and you cannot expect the package to work if those files are completely missing. > So that /etc is admin territory where the admin makes changes from the > defaults. That does not conflict with creating an initial config file that sets up zram, either as a %config(noreplace) file in a package, or as an unpackaged (or %ghost-ed) file written by Anaconda (or Calamares or whatever you use to install the system). A lot of existing distribution defaults work that way. That config file can also be the existing /etc/fstab, which already works exactly that way. IMHO, the fewer places we have mounting things, the better. So I want to see ALL default mounts added to /etc/fstab rather than to some magic generator or .mount file, also that magic tmpfs.mount. (I see no valid reason for that not to simply be a line in /etc/fstab.) Having it all in one place makes it much easier for administrators to customize. > Thus, if zram is something to use by default then it should not be stored > in /etc. Thus, I think that this is a non-sequitur. There is nothing wrong with shipping default settings in /etc. It is much better than hardcoding defaults in magic generators somewhere in /usr and requiring users/admins to mask them to turn off the features they do not want (which means that they have to hunt down where the automagic mounting comes from to begin with, which is a huge waste of time for local administrators). Your argument that /etc/fstab still works is not really valid because it only works to add mounts or to replace automagic mounts with some other mount, but there is no fstab syntax to actually completely disable the automagic (because fstab was designed to be the very place where automatic mounts are listed, so why would it have needed a syntax to disable a mount coming from elsewhere?), so one has to mask the systemd file doing the automagic in systemd instead, it cannot be done from /etc/fstab. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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:
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Mon, 2020-06-08 at 22:54 +, Konstantin Kharlamov wrote: > > On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones > > > > > (ZRAM) > > Compression is intrinsic to just the /dev/zram device. The swap > > code > > doesn't share pages between swap devices. The higher priority > > device > > is favored first until full. Once full, pages don't go through the > > zram module, thus are not compressed, on their way to the > > swap-on-disk. > > > > (ZSWAP) > > So yeah, the swap-on-disk scenario might be better suited to a > > generator that could use zswap instead, which uses an existing swap > > partition and adds a write back cache (zpool) rather than a > > separate > > device. I'm pretty sure (not 100%) that cached page are > > decompressed > > on their way to the swap device. Also, the zpool memory cache is > > preallocated, unlike zram devices. > > > > (I am not going to envy any who decide to implement zswap on a > > system > > with ZFS. Wait wait wait, which zpool are you talking about?!) > > So, I am testing ZRAM right now (as per your advice in another > thread). All well > so far, however reading this makes me think I gonna stumble upon a > point where > ZSRAM will be a better fit. > > You see, the idea of ZRAM and ZSWAP is improving low-memory > situation. This is > especially relevant for small amount of RAM, like your Raspberry > example. > > In such situation if you, for example, open a lot of tabs in a > browser, you may > easily get to a point where even ZRAM is exhausted. Now, had you > additionally a > SWAP device, it would be no problem, the data would simply spill over > to SWAP. > > Yes, SWAP is slow (well, it is on HDD at least). But consider this: > in this > workload , you most likely not gonna touch older of browser tabs for > quite some > time, so the slowness won't hurt you. > > My point is that we still need disk swap. And if we have disk swap, > we'd want to > move into SWAP the most unused memory pages. Which is how it works > with > ZSWAP. But not how it works with ZRAM (in which case, as you noted, > once it's > full, all new data would simply go past ZRAM into disk SWAP) > > - > > Now, I love the idea of using either ZRAM or ZSWAP. But to consider > which one of > them do we want, I think we would need to discuss first: do we really > want to get > rid of disk swap? Hibernation being discussed somewhere in this > thread is another > point. I personally don't like idea of removing disk swap. I should've added: browsing the Internet and watching video/reading social networks, and perhaps playing some browser games in their spare time, is a common activity for many people. I.e. the workload mentioned should be popular enough to take into consideration. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
> On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones wrote: > > (ZRAM) > Compression is intrinsic to just the /dev/zram device. The swap code > doesn't share pages between swap devices. The higher priority device > is favored first until full. Once full, pages don't go through the > zram module, thus are not compressed, on their way to the > swap-on-disk. > > (ZSWAP) > So yeah, the swap-on-disk scenario might be better suited to a > generator that could use zswap instead, which uses an existing swap > partition and adds a write back cache (zpool) rather than a separate > device. I'm pretty sure (not 100%) that cached page are decompressed > on their way to the swap device. Also, the zpool memory cache is > preallocated, unlike zram devices. > > (I am not going to envy any who decide to implement zswap on a system > with ZFS. Wait wait wait, which zpool are you talking about?!) So, I am testing ZRAM right now (as per your advice in another thread). All well so far, however reading this makes me think I gonna stumble upon a point where ZSRAM will be a better fit. You see, the idea of ZRAM and ZSWAP is improving low-memory situation. This is especially relevant for small amount of RAM, like your Raspberry example. In such situation if you, for example, open a lot of tabs in a browser, you may easily get to a point where even ZRAM is exhausted. Now, had you additionally a SWAP device, it would be no problem, the data would simply spill over to SWAP. Yes, SWAP is slow (well, it is on HDD at least). But consider this: in this workload , you most likely not gonna touch older of browser tabs for quite some time, so the slowness won't hurt you. My point is that we still need disk swap. And if we have disk swap, we'd want to move into SWAP the most unused memory pages. Which is how it works with ZSWAP. But not how it works with ZRAM (in which case, as you noted, once it's full, all new data would simply go past ZRAM into disk SWAP) - Now, I love the idea of using either ZRAM or ZSWAP. But to consider which one of them do we want, I think we would need to discuss first: do we really want to get rid of disk swap? Hibernation being discussed somewhere in this thread is another point. I personally don't like idea of removing disk swap. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
> On Fri, Jun 5, 2020 at 4:35 AM Vitaly Zaitsev via devel > > Already discussed in the 'support hibernation' thread. > > Most laptops today have UEFI Secure Boot enabled by default and > therefore hibernation isn't possible. And even when the laptop doesn't > have Secure Boot enabled, there's a forest of bugs. It works for some > people and not others. It was working for me on one laptop in > February, consistently doesn't work now and I haven't gotten a reply > yet from upstream about the problem. > > > I am a fan of zswap too, but it needs deconfliction logic with > swap-on-zram. The generator would need to come after the > fstab-generator, so that it could know if there is a swap-on-drive > partition. From that it could do swap-on-zram if there is no > swap-on-drive. And setup zswap if there is (instead of two swap > devices). The kernel has support for 32 swap devices, since almost > forever. > > I've done enough testing with zswap in all the same conditions I've > used zram, that I'm confident this can be implemented with this > feature in the F33 time frame. But someone needs to help out with the > zram-generator code to teach it how to use zswap. There is a sysfs > interface to do it so that's pretty straightforward and I think that's > how zram-generator does things now for zram, it's not yet using > zramctl for setup. > > I can plan to have supplementary tests for zswap on the test day. > Hypothetically zswap is a bit smarter because of the LRU basis it uses > to decide what to toss out of the memory cache to the swap-on-drive. > Whereas two swaps where /dev/zram0 has higher priority, gets favored > until it's full, then uses /dev/swapondrive. But in my testing I > haven't been able to prove zswap is better. Well, recent articles on LWN mention a spike in interest to hibernation¹, so I'd expect hibernation to get improved. And I'm not sure it's fair to rule out hibernation forever because of existing problems on some hw setups. Windows 10 has by default a thing called "fast startup" which is AFAIK simply hibernation. If that works for them, I guess we can make it too? 1: https://lwn.net/Articles/821158/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sa, 06.06.20 02:19, Kevin Kofler (kevin.kof...@chello.at) wrote: > Chris Murphy wrote: > > So yes it's well suited for these cases and the proposal does include > > them. If they wish to be left out, that's up to those working groups. > > It's possible to make sure /etc/systemd/zram-generator is not present. > > Also, why does this have to be a systemd generator? As a user administrating > his own systems, I find those to be extremely annoying, because they do > stuff behind my back that I never asked to happen and I have to mask them > (and/or uninstall them completely) to get rid of the unwanted behavior. > > E.g., the systemd generator that tries to automount partitions not listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap partition > I have on my SSD in case I ever need it, which is normally NOT mounted to > avoid wearing out the SSD). So why does systemd want to second-guess me and > mount that partition behind my back unless I go out of my way to mask the > magic generator? Well, if you don#t want that behaviour don't use the partition type UUIDs from the "discoverable partition spec" for your partitions. It's how these type uuids are defined: https://systemd.io/DISCOVERABLE_PARTITIONS/ By using these partition type uuids you basically say: "please automatically mount me, thank you". > So why can this zram feature not be a line in fstab, a parameter passed > through the kernel CLI, or some other solution that is easily tweakable and > that will definitely not affect upgrades of existing installations (unlike > yet another systemd generator, if it happens to get installed for whatever > reason)? I am sorry, but in this day and age I am sure we should default to stuff that just works, and that means: defaults should apply with empty or immutable /etc. By making this a default but list it in a configuration file to work, you require /etc to be writable or populated, and that just sucks. > IMHO, the only systemd generator that should ever mount partitions of any > kind (including virtual ones such as zram) is the systemd-fstab-generator. > If you want more stuff mounted, it should be added to /etc/fstab, that's > what that file is for! I disagree. We should strive for a system that works with empty /etc/ and if booted that way uses default settings. So that /etc is admin territory where the admin makes changes from the defaults. Thus, if zram is something to use by default then it should not be stored in /etc. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Mon, Jun 08, 2020 at 10:58:12AM +0100, Richard W.M. Jones wrote: > On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: > > On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann wrote: > > > > > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > > > > To me this sounds like too much dependency on swap. > > > > > > That's not what I meant, I wanted to emphasize the different values of > > > disk storage vs. RAM. As said in another email it doesn't matter at all > > > if there is 0% or 90% of disk swap usage, while RAM usage can be quite > > > essential. (This is in case swapped out stuff stays swapped out.) > > > > Inactive pages that are evicted long term, is a workload that I think > > would benefit from zswap instead. In that case you get the benefit of > > the memory cache for recently used anonymous pages that would > > otherwise result in "swap thrashing" and the "least recently used" > > pages are moved to disk based swap. > > Is this how it works? Previously it was stated that once a page is > swapped to a particular swap device, that's it. It would be nice if a > page which has been sitting in zram for a while could be swapped out > to the slower / cheaper / larger disk. It seems possible: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#writeback -- Tomasz Torcz “God, root, what's the difference?” to...@pipebreaker.pl “God is more forgiving.” ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: > On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann wrote: > > > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > > > To me this sounds like too much dependency on swap. > > > > That's not what I meant, I wanted to emphasize the different values of > > disk storage vs. RAM. As said in another email it doesn't matter at all > > if there is 0% or 90% of disk swap usage, while RAM usage can be quite > > essential. (This is in case swapped out stuff stays swapped out.) > > Inactive pages that are evicted long term, is a workload that I think > would benefit from zswap instead. In that case you get the benefit of > the memory cache for recently used anonymous pages that would > otherwise result in "swap thrashing" and the "least recently used" > pages are moved to disk based swap. Is this how it works? Previously it was stated that once a page is swapped to a particular swap device, that's it. It would be nice if a page which has been sitting in zram for a while could be swapped out to the slower / cheaper / larger disk. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 2020-06-07 11:29 p.m., Chris Murphy wrote: On Sun, Jun 7, 2020 at 11:25 PM Luya Tshimbalanga wrote: On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga Good to know. I proceed to remove on my desktop which has 32 GB RAM. I'm not sure whose service this is but I don't have it. After removing both anaconda and zram package, the result is systemctl status zram-setup@zram0.service ● zram-setup@zram0.service - Setup zram based device zram0 Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor preset: disabled) Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > /sys/class/block/zram0/max_comp_streams (code=exited, s> Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > /sys/class/block/zram0/disksize (code=exited, status=1> Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, st> Main PID: 882 (code=exited, status=1/FAILURE) CPU: 4ms This suggests the mkswap failed which might happen if this device is already active, and somehow this service is from something else. Maybe do: dnf provides /usr/lib/systemd/system/zram-setup@.service The command revealed udisks2-zram, a module for zram, was the provided package. Once removed it, there no more service related to zram after reboot. I confirm zram is now active as seem on my laptop. journalctl --no-hostname -b -o short-monotonic | grep 'swap\|zram' [ 0.468101] kernel: Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization [ 1.395800] kernel: zswap: loaded using pool lzo/zbud [ 1.411736] kernel: Lockdown: swapper/0: hibernation is restricted; see man kernel_lockdown.7 [ 4.408224] systemd[1]: Created slice system-swap\x2dcreate.slice. [ 4.448207] kernel: zram: Added device: zram0 [ 4.399416] systemd-modules-load[592]: Inserted module 'zram' [ 4.614307] systemd[1]: Found device /dev/zram0. [ 4.614638] systemd[1]: Starting Create swap on /dev/zram0... [ 4.992881] kernel: zram0: detected capacity change from 0 to 7838105600 [ 4.697841] mkswap[636]: Setting up swapspace version 1, size = 7.3 GiB (7838101504 bytes) [ 4.697841] mkswap[636]: no label, UUID=69e8bc81-6456-470a-be0d-8f3319d11df4 [ 4.703285] systemd[1]: swap-create@zram0.service: Succeeded. [ 4.704332] systemd[1]: Finished Create swap on /dev/zram0. [ 4.704783] audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=swap-create@zram0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 4.704876] audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=swap-create@zram0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' [ 4.711170] systemd[1]: Activating swap Compressed swap on /dev/zram0... [ 5.066565] kernel: Adding 7654396k swap on /dev/zram0. Priority:-2 extents:1 across:7654396k SSFS [ 4.749250] systemd[1]: Activated swap Compressed swap on /dev/zram0. [ 10.991487] earlyoom[804]: mem total: 14951 MiB, swap total: 7474 MiB [ 10.991487] earlyoom[804]: sending SIGTERM when mem <= 2.68% and swap <= 10.00%, [ 10.991660] earlyoom[804]: SIGKILL when mem <= 1.34% and swap <= 5.00% Thank you for the helps. I found the process is much easier to do. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 6, 2020 at 4:55 PM Chris Murphy wrote: > Also, the zpool memory cache is > preallocated, unlike zram devices. Nevermind. This is also dynamic. "dynamically allocated RAM-based memory pool" https://www.kernel.org/doc/Documentation/vm/zswap.txt -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 06, 2020 at 03:10:37PM -0700, Samuel Sieb wrote: > On 6/6/20 9:04 AM, Richard W.M. Jones wrote: > >On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: > >>This laptop with 8GiB RAM is running two VMs at the same time: Windows > >>10 and Fedora Workstation 32. The host is Fedora Workstation 32. > > > >So this suggests another interesting question: If I have Fedora > >virtual machines running on a Fedora host, and both are using zram, > >could there be some negative interaction? ie. With the pages not > >being compressible twice. I suppose (without looking at the source) > >that zram will skip compressing a page if the compressed page is not > >any smaller? > > I considered this as well. But that would only be a concern if the > live memory of the VM is getting swapped out. Is that something > that could happen? That's a good point. The answer is yes (VMs are just regular processes). However usually if that does happen then the end result isn't great, with potentially huge guest pauses when a guest tries to run and its memory needs to be swapped back in. Serious virtualization hosts will try to ensure that memory is not overcommitted like this. KSM (kernel samepage merging) might also be affected. I wonder if the same original page content always compresses to exactly the same zram page? I'm going to guess not, in which case KSM would be defeated by zram. Although personally I've never found KSM does anything. https://www.linux-kvm.org/page/KSM Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Igor Raits wrote: > Why is it painful? You have all dependencies packaged that follow > semver (not like Go) and it is quite easy to build those packages. Semver is just a convention on version numbers (and one that, IMHO, is still open to human interpretation). It does not solve the problem at hand, which is that even the compiler does not provide a stable ABI when it changes version (affecting all libraries), let alone the libraries. (Semver only says that incompatible API changes should lead to a bump in the front rather than the back of the version number. That does not solve the problem that incompatibilities happen to begin with. At least not as long as any upstream can set any version number they wish at any time they wish.) The lack of stable ABIs is what prevents building shared libraries in a way useful to the distribution. Semver is not relevant there. > Another example here could be nodejs, even though it does not link > statically it is just PITA to package since ecosystem is just full of > very small libraries that do not really like to cooperate so you need > to have tens of different versions of a lib in a repo. I consider this > much bigger problem than the Rust has in Fedora. IMHO, Rust and Go also have this exact same "[many] very small libraries" problem. Maybe slightly fewer than Node.js, which really takes it to an extreme, but still a lot more than C or C++. The main issue is that it is too easy to depend on a library in all of Node.js, Rust, and Go, because you just have to write one import line, and the programming language's tooling will automagically pull the dependency from the Internet. This is what leads to dependency explosion. It is also a PITA for packaging, because Koji rightfully (for obvious security reasons) prevents builds from accessing the Internet. In a language like C or C++, the developer thinks twice before adding yet another dependency. > We also have Fedora CoreOS that uses > https://github.com/coreos/afterburn and > https://github.com/coreos/zincati that are written in Rust as well and > those are core system utilities. The situation there is essentially the same as for rpm-ostree: Those are core system utilities for CoreOS only, not for a default Fedora installation. This is yet another decision that makes Fedora CoreOS unattractive to me. > I don't think saying "Ditch Python, Ruby, Perl, … from the system > components" is useful for anyone since you know that it is not going to > happen. Actually, Ruby and Perl are already undesired in the core system layer, because each language interpreter increases the size of all our live images. There was an official effort to kick out Perl from the Workstation live image years ago, which AFAIK has been fully implemented. And Ruby was never used in the core system to begin with. Python is a different story. There are people who are trying to get rid of even that (see, e.g., microdnf), but in the default Fedora, it is probably here to stay. I consider that unfortunate, because it is a heavy runtime dependency, because it is more error-prone than fully compiled languages (only syntax errors are caught at package build time, and even that only if bytecode generation is set up correctly, whereas, e.g., type errors, deprecation warnings, etc. are all spewed at the end user instead), because it is not fully backwards compatible (even a new 3.n+1 release can have small incompatibilities, and the transition from 2 to 3 was a huge breakage), and because it does not perform as well as natively compiled code. But I am not entitled to make this decision. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Nicolas Mailhot via devel wrote: > And Go has all build dependencies in the release where they are used > (not like rust, with magic ephemeral rawhide-only packages) Ephemeral Rawhide-only packages mean the builds cannot be reproduced in a release, which is a clear violation of our packaging guidelines. What if a security update is needed? (Yes, I know the language claims to be totally secure by design. But that is at most true for a small number of security vulnerability classes, such as buffer overflows.) And if the software is under the GNU GPL or a similar strong copyleft license, it is also a violation of the license. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020 at 11:25 PM Luya Tshimbalanga wrote: > > > On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga > > > > > zram-generator has no service unit file at all. The zram.service unit > > file is part of Anaconda. > > > Good to know. I proceed to remove on my desktop which has 32 GB RAM. > > > > > > I'm not sure whose service this is but I don't have it. > > > After removing both anaconda and zram package, the result is > > systemctl status zram-setup@zram0.service > ● zram-setup@zram0.service - Setup zram based device zram0 > Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; > vendor preset: disabled) > Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago > Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > > /sys/class/block/zram0/max_comp_streams (code=exited, s> > Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > > /sys/class/block/zram0/disksize (code=exited, status=1> > Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap /dev/zram0 > && swapon /dev/zram0 (code=exited, st> >Main PID: 882 (code=exited, status=1/FAILURE) > CPU: 4ms This suggests the mkswap failed which might happen if this device is already active, and somehow this service is from something else. Maybe do: dnf provides /usr/lib/systemd/system/zram-setup@.service If that doesn't reveal anything, maybe this will reveal something: journalctl -b | grep 'swap\|zram' > Done but these minor conflicts still remained. Maybe filing a bug related to > that issue? Might give a shot on here first. Someone else may run into it, and look in thread for a fix. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
> On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga > > zram-generator has no service unit file at all. The zram.service unit > file is part of Anaconda. > Good to know. I proceed to remove on my desktop which has 32 GB RAM. > > I'm not sure whose service this is but I don't have it. > After removing both anaconda and zram package, the result is systemctl status zram-setup@zram0.service ● zram-setup@zram0.service - Setup zram based device zram0 Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor preset: disabled) Active: active (exited) since Sun 2020-06-07 22:08:36 PDT; 4min 57s ago Process: 856 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > /sys/class/block/zram0/max_comp_streams (code=exited, s> Process: 879 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > /sys/class/block/zram0/disksize (code=exited, status=1> Process: 882 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, st> Main PID: 882 (code=exited, status=1/FAILURE) CPU: 4ms It seems the script failed to properly read the last two variables. > This service is not permanent it's created by the generator, and is > the only service unit I see. > Jun 03 00:47:53 flap.local systemd[1]: swap-create(a)zram0.service: Succeeded. > I got the same result from the journalctl: systemd[1]: swap-create@zram0.service: Succeeded. > > Conflicting implementations. I recommend removing both anaconda and > zram packages. Keep zram-generator package. Done but these minor conflicts still remained. Maybe filing a bug related to that issue? > > It's no longer needed. This is a hibernation hint. If you have no need > for hibernation, you can remove it. If you have disabled/removed the > disk based swap partition/LV then you can also remove this resume > hint, because you can't hibernate anyway. > Done. Hibernation was never used as the system has secure-boot enabled by default -- Luya Tshimbalanga Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020 at 7:31 PM David Kaufmann wrote: > > Yes, its a quite boring example, but I've included it for completeness > as a border case. This is just the few megabytes it needs preallocated, > whilst swap is not in use at all. 12KiB when not in use? $ swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 3.8G 0B -2 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 4K 74B 12K 4 [SWAP] $ And for the zram module: zram 28672 1 > > >> At 150% memory usage assuming a 2:1 compression ratio this would mean: > >> - disk swap: > >> has to write 4G to disk initially, and for reading swap another 4G > >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) > >> - zram, assuming 4G zram swap: > >> has to write 8G to zram initially, and for reading the data swap 16G > >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) > > > > swap contains anonymous pages, so I'm not sure what you mean by > > initial. Whether these pages are internet or typed in or come from > > persistent storage - it's a wash between disk or zram swap so it can > > be ignored. > > I was calculating it from the viewpoint of data, e.g. paging out a > certain amount of data, and paging it in again. "Initial" would be the > amount of data when paging in. > What is definitely different is that I thought of 1 or 2 processes > eating away memory, but not of many thrashing swap. For those it is > definitely not possible to recover from it once thrashing has started. > > > Also I don't understand any of your math,how you start with a 4G zram > > swap but have 8G. I think you're confused. The cap of 4GiB is the > > device size. The actual amount of RAM it uses will be less due to > > compression. The zram device size is not the amount of memory used. > > And in no case is there a preallocation of memory unless the zram > > device is used. It is easy to get confused, by the way. That was my > > default state for days upon first stumbling on this. > > I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a > 4G zram device. That's not how it works. A /dev/zram0 device size of 4G, means a swap device size of 4G, and at a 2:1 compression means memory usage is 2G. If the compression ratio is 1:1, then memory usage is 4G If the compression ratio is 4:1, then memory usage is 1G There are more options in sysfs to tweak the behavior of the zram device, including an option to specifically limit memory use. This is not used by zram-generator. And I haven't done any testing of it, because while it could be useful for other applications, I think it could be bad if there's a hard limit of memory reached before the swap device is full. I have no idea what kernel behavior is like if swap claims to be 4G but then just stops accepting writes at 3G. I think it could mean kernel panic or just bad news. So I haven't gone down this road. > > earlyoom will kill in such a case even if you can't. It's configurable > > and intentionally simplistic, based on memory and swap free > > percentage. > > I don't have any experience with it, as I use the time from slowdown > until OOM to try to manage the issue myself, usually successful. > But as mentioned above, I might have a specialized usecase, so my > experience might not reflect the average users' experience. earlyoom is enabled by default in Fedora Workstation 32. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020, at 9:30 PM, David Kaufmann wrote: > On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: > > >> At 150% memory usage assuming a 2:1 compression ratio this would mean: > >> - disk swap: > >> has to write 4G to disk initially, and for reading swap another 4G > >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) > >> - zram, assuming 4G zram swap: > >> has to write 8G to zram initially, and for reading the data swap 16G > >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) > > > > swap contains anonymous pages, so I'm not sure what you mean by > > initial. Whether these pages are internet or typed in or come from > > persistent storage - it's a wash between disk or zram swap so it can > > be ignored. > > I was calculating it from the viewpoint of data, e.g. paging out a > certain amount of data, and paging it in again. "Initial" would be the > amount of data when paging in. > What is definitely different is that I thought of 1 or 2 processes > eating away memory, but not of many thrashing swap. For those it is > definitely not possible to recover from it once thrashing has started. > > > Also I don't understand any of your math,how you start with a 4G zram > > swap but have 8G. I think you're confused. The cap of 4GiB is the > > device size. The actual amount of RAM it uses will be less due to > > compression. The zram device size is not the amount of memory used. > > And in no case is there a preallocation of memory unless the zram > > device is used. It is easy to get confused, by the way. That was my > > default state for days upon first stumbling on this. > > I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a > 4G zram device. I've calculated with filling the zram device to the > max, so it will use the full 4G. (the 4G limit was arbitrarily chosen) > A 4G zram device is 4G apparent size. The amount of memory it takes will vary based on the compression, but in no case take more than 4G memory. The max uncompressed data that can be put in a 4G zram device is 4G of data. V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote: >> This is not generally true, only if RAM gets so tight that applications >> start competing for swap. >> This is why I've proposed test cases testing exactly that, as for >> the case of persistent swap I'd expect the outcome to be a clear win for >> disk swap. (Although this can in some cases also be seen as bug, as this >> would be applications not really using the allocated space) > > I don't follow this. Where are the proposed test cases? And also in > what case are you saying disk swap is a clear win? I was referencing the testcases from the email before that, but your webkitgtk compile might also work for that. What I described as persistent swap is stuff that gets swapped out and not swapped back in for hours or days. >> Until about 95% mem usage I'd expect the disk swap case to win, as it >> should behave the same as no swap (with matching swappiness values) > > Why would disk based swap win? In this example, where there's been no > page outs, the zram device isn't using any memory. Again, it is not a > preallocation. Yes, its a quite boring example, but I've included it for completeness as a border case. This is just the few megabytes it needs preallocated, whilst swap is not in use at all. >> At 150% memory usage assuming a 2:1 compression ratio this would mean: >> - disk swap: >> has to write 4G to disk initially, and for reading swap another 4G >> (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) >> - zram, assuming 4G zram swap: >> has to write 8G to zram initially, and for reading the data swap 16G >> (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) > > swap contains anonymous pages, so I'm not sure what you mean by > initial. Whether these pages are internet or typed in or come from > persistent storage - it's a wash between disk or zram swap so it can > be ignored. I was calculating it from the viewpoint of data, e.g. paging out a certain amount of data, and paging it in again. "Initial" would be the amount of data when paging in. What is definitely different is that I thought of 1 or 2 processes eating away memory, but not of many thrashing swap. For those it is definitely not possible to recover from it once thrashing has started. > Also I don't understand any of your math,how you start with a 4G zram > swap but have 8G. I think you're confused. The cap of 4GiB is the > device size. The actual amount of RAM it uses will be less due to > compression. The zram device size is not the amount of memory used. > And in no case is there a preallocation of memory unless the zram > device is used. It is easy to get confused, by the way. That was my > default state for days upon first stumbling on this. I assumed a 2:1 compression rate, so the zram swap holds 8G of data in a 4G zram device. I've calculated with filling the zram device to the max, so it will use the full 4G. (the 4G limit was arbitrarily chosen) > This task only succeeds with ~12+G of disk based swap. Which is just > not realistic. It's a clearly overcommitted and thus contrived test. This sounds like it's just failing earlier. But it's still a test case. > But I love it and hate it at the same time. More realistic is to not > use defaults, and set the number of jobs manually to 6. And in this > case, zram based swap consistently beats disk based swap. > Which makes sense because pretty much all of the inactive pages are > going to be needed at some point by the compile or they are dropped. > Following the compile there aren't a lot of inactive pages left, and > I'm not sure they're even related to the compile at all. Especially for a compile those pages are needed quite soon, so thrashing occurs earlier too. For this it makes a lot of sense that zram is a big benefit for it. When I reached the memory limit my usecase was usually having chrome and firefox open, with firefox having about 500 open tabs, so most of the data could stay in swap until I triggered swap in, which is very different from a compiling. > Even under manual control we've got examples of the GUI becoming > completely stuck. Long threads in devel@ based on this Workstation > working group issue - with the same name. So just search archives for > interactivity. Or maybe webkitgtk. I'm afraid I've read most of those, I usually read all mails to devel@. So far it seemed mostly like exceptions, but it might also be a specific configuration on my systems and this issue is more widespread. > earlyoom will kill in such a case even if you can't. It's configurable > and intentionally simplistic, based on memory and swap free > percentage. I don't have any experience with it, as I use the time from slowdown until OOM to try to manage the issue myself, usually successful. But as mentioned above, I might have a specialized usecase, so my experience might not reflect the average users' experience. All the best, David signature.asc Description: PGP
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann wrote: > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > > To me this sounds like too much dependency on swap. > > That's not what I meant, I wanted to emphasize the different values of > disk storage vs. RAM. As said in another email it doesn't matter at all > if there is 0% or 90% of disk swap usage, while RAM usage can be quite > essential. (This is in case swapped out stuff stays swapped out.) Inactive pages that are evicted long term, is a workload that I think would benefit from zswap instead. In that case you get the benefit of the memory cache for recently used anonymous pages that would otherwise result in "swap thrashing" and the "least recently used" pages are moved to disk based swap. The inherent difficulty with optimizations, is trying to find a generic approach that helps most use cases. Is this a 100% winner? I doubt it. Is it an 80% winner across all of Fedora? I think it's at least that but sure, I can't prove it empirically. There's quite a lot of evidence it's sane considering all the use cases it's already been used in. > > > What people hate is slow swap. > > This is not generally true, only if RAM gets so tight that applications > start competing for swap. > This is why I've proposed test cases testing exactly that, as for > the case of persistent swap I'd expect the outcome to be a clear win for > disk swap. (Although this can in some cases also be seen as bug, as this > would be applications not really using the allocated space) I don't follow this. Where are the proposed test cases? And also in what case are you saying disk swap is a clear win? Because I would consider such an example an optimization for that specific edge case, rather than a generic solution. We've had that as a generic solution for a while and it's causing some grief for folks where there is memory competition among applications and those pages need to be evicted and then not long after paged in - which causes the swap thrashing effect. Arguably they need more memory for their workload. But that's in effect what the feature does. It gives them more bandwidth for frequently used anonymous pages being paged in and out via compressed memory rather than significantly slower disk swap. Is this free? Well, it's free in that it's not out of pocket cost for more RAM. Instead it exchanges some CPU to make extra room in existing memory and not have the explosively high latency of disk swap give them a bad experience. > > > For sure there is an impact on CPU. This exchanges IO bound work, for > > CPU and memory bound work. But it's pretty lightweight compression. > > > > And again, whatever is defined as "too much" CPU hit for the workload, > > necessarily translates into either "suffer the cost of IO bound > > swap-on-drive, or suffer the cost of more memory." There is no free > > lunch. It really isn't magic. > > Yes, that seems obvious to me. What would be interesting is the point, > where one is significantly slower than the other one. > The theoretical testcase is writing data to memory and reading it again. > For this case I'm assuming 8G RAM as total memory. > > Until about 95% mem usage I'd expect the disk swap case to win, as it > should behave the same as no swap (with matching swappiness values) Why would disk based swap win? In this example, where there's been no page outs, the zram device isn't using any memory. Again, it is not a preallocation. > At 150% memory usage assuming a 2:1 compression ratio this would mean: > - disk swap: > has to write 4G to disk initially, and for reading swap another 4G > (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) > - zram, assuming 4G zram swap: > has to write 8G to zram initially, and for reading the data swap 16G > (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) swap contains anonymous pages, so I'm not sure what you mean by initial. Whether these pages are internet or typed in or come from persistent storage - it's a wash between disk or zram swap so it can be ignored. Also I don't understand any of your math,how you start with a 4G zram swap but have 8G. I think you're confused. The cap of 4GiB is the device size. The actual amount of RAM it uses will be less due to compression. The zram device size is not the amount of memory used. And in no case is there a preallocation of memory unless the zram device is used. It is easy to get confused, by the way. That was my default state for days upon first stumbling on this. > It would be good to see actual numbers for this, so far I've only > seen praises on how well the compression ratio is. (Plus the anecdotal > references from a few people) There's a lot of use cases using this in the real world: Chrome, Android, Fedora IoT, Fedora ARM spins, most all of openQA VM's doing Anaconda installation tests are taking advantage of it. > But this should also be tested with actual CPUs and disks.
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sun, Jun 7, 2020 at 1:26 PM Luya Tshimbalanga wrote: > > Tested on HP Envy x360 Convertible Ryzen 2500u with 16 GB RAM and 1TB > SSD on Fedora 32 Design Suite. > > Following the procedure to install zram-generator setting memory > allocation to 0.50 (or 50%) and commenting out "resume=UUID" line on > fstab and kernel parameter on boot via grubby, the allocated 14 GB RAM > Swap partition from the installer is deleted. > > zram-swap service is manually disabled via systemctl so the system only > use zram service. zram-generator has no service unit file at all. The zram.service unit file is part of Anaconda. > After reboot here is the observation > > -- > > zram-setup@zram0.service - Setup zram based device zram0 > Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; > static; vendor preset: disabled) > Active: active (exited) since Sun 2020-06-07 10:11:20 PDT; 1h > 31min ago > Process: 809 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > > /sys/class/block/zram0/max_comp_streams (code=exited, status=0/SUCCESS) > Process: 813 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > > /sys/class/block/zram0/disksize (code=exited, status=1/FAILURE) > Process: 815 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap > /dev/zram0 && swapon /dev/zram0 (code=exited, status=1/FAILURE) > Main PID: 815 (code=exited, status=1/FAILURE) > CPU: 9ms I'm not sure whose service this is but I don't have it. This service is not permanent it's created by the generator, and is the only service unit I see. Jun 03 00:47:53 flap.local systemd[1]: swap-create@zram0.service: Succeeded. > I don't know the cause of failure on the process although the zram0 > seems ok. I would like a pointer to address those minor issues. Conflicting implementations. I recommend removing both anaconda and zram packages. Keep zram-generator package. > > zramctl > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lzo-rle 7.3G 4K 74B 12K 8 [SWAP] > > swapon > NAME TYPE SIZE USED PRIO > /dev/zram0 partition 7.3G 0B -2 Looks good. > Is "resume=UUID" necessary for the boot parameter? I removed it as it > cause longer delay on boot and the swap partition is deleted. It's no longer needed. This is a hibernation hint. If you have no need for hibernation, you can remove it. If you have disabled/removed the disk based swap partition/LV then you can also remove this resume hint, because you can't hibernate anyway. > I noticed a more responsive system compared with the traditional setting > with swap partition. Suspend is working as intended despite a slight > flashing display on resume (which could be from the driver i.e. amdgpu > in this case). > > Overall, the proposal makes sense with the real test done on both ARM > devices like Android and Chromebook in addition of Anacona. It will be > great to get accepted. Cool! -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote: > To me this sounds like too much dependency on swap. That's not what I meant, I wanted to emphasize the different values of disk storage vs. RAM. As said in another email it doesn't matter at all if there is 0% or 90% of disk swap usage, while RAM usage can be quite essential. (This is in case swapped out stuff stays swapped out.) > What people hate is slow swap. This is not generally true, only if RAM gets so tight that applications start competing for swap. This is why I've proposed test cases testing exactly that, as for the case of persistent swap I'd expect the outcome to be a clear win for disk swap. (Although this can in some cases also be seen as bug, as this would be applications not really using the allocated space) > For sure there is an impact on CPU. This exchanges IO bound work, for > CPU and memory bound work. But it's pretty lightweight compression. > > And again, whatever is defined as "too much" CPU hit for the workload, > necessarily translates into either "suffer the cost of IO bound > swap-on-drive, or suffer the cost of more memory." There is no free > lunch. It really isn't magic. Yes, that seems obvious to me. What would be interesting is the point, where one is significantly slower than the other one. The theoretical testcase is writing data to memory and reading it again. For this case I'm assuming 8G RAM as total memory. Until about 95% mem usage I'd expect the disk swap case to win, as it should behave the same as no swap (with matching swappiness values) At 150% memory usage assuming a 2:1 compression ratio this would mean: - disk swap: has to write 4G to disk initially, and for reading swap another 4G (12G total traffic - 4G initial, 4G swapping out and 4G swapping in) - zram, assuming 4G zram swap: has to write 8G to zram initially, and for reading the data swap 16G (24G total traffic - 8G initial, 8G swapping out and 8G swapping in) It would be good to see actual numbers for this, so far I've only seen praises on how well the compression ratio is. (Plus the anecdotal references from a few people) But this should also be tested with actual CPUs and disks. zram is obviously faster, but at which point is the overhead from compression, the reduced unswapped memory and the doubled number of swapping operations starting to be smaller than the overhead from SSD read/write speed? Is this almost immediately the case or is this only closely before being OOM anyway? The "too much CPU" limit would be the actual wallclock time testprograms take without hitting OOM. If a program using 120% memory takes 90 seconds to complete its run with swap, and 60 seconds with zram swap, that would be an improvement. If it's 120 seconds the most likely issue is "too much CPU used for compression or swapping". > One thing this might alter the calculus of is swappiness. Because the > zram device is so much faster, page out page in is a lower penalty > than file reclaim reads. So now instead of folks thinking swappiness > should be 1 (or even 0), it's the opposite. It probably should be 100. > > See the swappiness section in the Chris Down article referenced in the > proposal: > https://chrisdown.name/2018/01/02/in-defence-of-swap.html This article states that setting swappiness to 100 could already be working fine on SSDs. But yes, swappiness definitely has an influence on this. I assume testing the edgecases (something around 2 and something around 100) should be enough. > There are worse things than OOM. Stuck with a totally unresponsive > system and no OOM on the way. Hence earlyoom. And on-going resource > control work with cgroupsv2 isolation. This is true boxes where the offending processes are not under manual control, where it's better that any exploding program is being terminated as soon as possible. It's exactly the other way round for manual controlled processes, as a slowdown before getting to OOM is sometimes enough to be able to decide what to free up/terminate, before OOM-Killer just goes in brute-force. That doesn't work too well nowadays, as quite often the swap on disk fills too fast on SSDs before I've got time to kill something. Usecase: I've got two browsers running, and I'm working in something memory intensive in one of them. When experiencing slowdown I'd like to kill the other one, and not terminate the more memory hungry where I'm currently working at. All the best, David signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Tested on HP Envy x360 Convertible Ryzen 2500u with 16 GB RAM and 1TB SSD on Fedora 32 Design Suite. Following the procedure to install zram-generator setting memory allocation to 0.50 (or 50%) and commenting out "resume=UUID" line on fstab and kernel parameter on boot via grubby, the allocated 14 GB RAM Swap partition from the installer is deleted. zram-swap service is manually disabled via systemctl so the system only use zram service. After reboot here is the observation -- zram-setup@zram0.service - Setup zram based device zram0 Loaded: loaded (/usr/lib/systemd/system/zram-setup@.service; static; vendor preset: disabled) Active: active (exited) since Sun 2020-06-07 10:11:20 PDT; 1h 31min ago Process: 809 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > /sys/class/block/zram0/max_comp_streams (code=exited, status=0/SUCCESS) Process: 813 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > /sys/class/block/zram0/disksize (code=exited, status=1/FAILURE) Process: 815 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap /dev/zram0 && swapon /dev/zram0 (code=exited, status=1/FAILURE) Main PID: 815 (code=exited, status=1/FAILURE) CPU: 9ms -- I don't know the cause of failure on the process although the zram0 seems ok. I would like a pointer to address those minor issues. zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 7.3G 4K 74B 12K 8 [SWAP] swapon NAME TYPE SIZE USED PRIO /dev/zram0 partition 7.3G 0B -2 Is "resume=UUID" necessary for the boot parameter? I removed it as it cause longer delay on boot and the swap partition is deleted. I noticed a more responsive system compared with the traditional setting with swap partition. Suspend is working as intended despite a slight flashing display on resume (which could be from the driver i.e. amdgpu in this case). Overall, the proposal makes sense with the real test done on both ARM devices like Android and Chromebook in addition of Anacona. It will be great to get accepted. -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 4:55 PM, John M. Harris Jr wrote: On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote: Great, then it probably wouldn't benefit you, but it also would not harm you at all either. In my case, my laptop was constantly thrashing the swap and now it isn't, so I'm very happy about it. What was causing it to be constantly thrashing? Instead of breaking traditional systems even further, and ignoring the users' choice during upgrade, why don't we address the actual cause of the problem that some seem to have which led to the suggestion of using zram? There you go with the "breaking" thing again. Nothing is getting broken! If you don't need to use the swap, then you won't even notice it. The only "problem" zram is solving is that disk swap is very slow so if you can keep the swap in ram, everything stays much faster. The cause of thrashing in my case is running several memory heavy applications. I have almost 50 Firefox windows with multiple tabs in each one, so likely 300 tabs open. Multi-process Firefox is very nice but it makes it difficult to get a good memory usage number, but it's probably over 6GB. I have a very large Inbox and many folders which probably contributes to Thunderbird often going to 2 or 3GB. I'm running Discord and various other applications. Did you read the article that Chris posted earlier? You're always going to want swap, so why not start with the very effective zram swap. It's probably all you'll need, but you can add some disk swap as well for any overflow. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Saturday, June 6, 2020 3:16:02 PM MST Samuel Sieb wrote: > On 6/6/20 10:41 AM, John M. Harris Jr wrote: > > > On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: > > > >> On 6/6/20 12:42 AM, John M. Harris Jr wrote: > >> > >> > >> > >>> On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, > >>> enabling swap on zram led to increased CPU usage (Always above 13% > >>> where > >>> normally idling at 6%!), and my entire system freezing after about 30 > >>> minutes. In all fairness, I don't know why my system froze, as I > >>> couldn't > >>> get anything over netconsole and sysrq wasn't working, but I think I'm > >>> going to leave it disabled. Swap on disk is more than fast enough for > >>> buffer/cache and hibernation/resume on my system. > >> > >> > >> > >> > >> I don't know why you had problems with it, but it's working on fine on > >> every system I've tried it on. It's not increasing my CPU usage. It's > >> probably actually lower due to less swap thrashing. > > > > > > There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my > > 8 GiB of swap. This is most likely the case for most casual users, those > > not compiling complex software on their system. This is with Firefox, > > Konversation, KMail, virt-manager and a few Konsole sessions open. > > Great, then it probably wouldn't benefit you, but it also would not harm > you at all either. In my case, my laptop was constantly thrashing the > swap and now it isn't, so I'm very happy about it. What was causing it to be constantly thrashing? Instead of breaking traditional systems even further, and ignoring the users' choice during upgrade, why don't we address the actual cause of the problem that some seem to have which led to the suggestion of using zram? -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Saturday, June 6, 2020 3:55:42 PM MST Chris Murphy wrote: > On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones > wrote: > > > > > > But let's say we also add a lower priority disk swap, then my next > > question ... > > > > > > > > > > Also does the swap partition on disk contain compressed pages, or > > > > uncompressed pages, or a mix of both? > > > > > > > > > > > > With zram there is no partition on disk, or was this question about > > > something else? > > > > > > > > ... means: Does this secondary swap partition (on disk) contain > > swapped out zram pages? Or uncompressed pages? (Or maybe the > > question just makes no sense, I don't really know.) > > > (ZRAM) > Compression is intrinsic to just the /dev/zram device. The swap code > doesn't share pages between swap devices. The higher priority device > is favored first until full. Once full, pages don't go through the > zram module, thus are not compressed, on their way to the > swap-on-disk. > > (ZSWAP) > So yeah, the swap-on-disk scenario might be better suited to a > generator that could use zswap instead, which uses an existing swap > partition and adds a write back cache (zpool) rather than a separate > device. I'm pretty sure (not 100%) that cached page are decompressed > on their way to the swap device. Also, the zpool memory cache is > preallocated, unlike zram devices. > > (I am not going to envy any who decide to implement zswap on a system > with ZFS. Wait wait wait, which zpool are you talking about?!) Which zswap are you talking about? Swap on compressed zvol has been called zswap at times. ;) - - John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 6, 2020 at 4:18 AM David Kaufmann wrote: > > Hi! > > On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: > > 5GB of swap space that normally would be on disk is now taking less than 2G > > of RAM. Instead of the usual 6G in the disk swap, now I have less than 2. > > What's bugging me about this thread is that quite a few people made > comparisions resulting in "compressed zram is smaller than uncompressed > disk swap". For me this seems quite obvious, and looks like flawed > testing. > > Wouldn't it be more correct to also compress disk swap to compare size? > This would probably make the size-argument void, as I'd expect them to > be the same size. If it's not, that would be an useful data point. > Also I don't care about 10GB stuff sitting in disk swap, whilst 1GB of > RAM could be quite essential. This leaves overall performance as a > potential benefit of zram swap. To me this sounds like too much dependency on swap. There is a balance. You really do want some swap, because incidental and occasional heavy swap, is merely inactive page eviction and it's good to get them out of the way because it frees memory for real work. And it avoids reclaim, which is what must happen in the noswap case. What people hate is slow swap. So the proposal is basically: let's use some fast swap and not a lot of slow swap. It's mainly an optimization. I expect special workloads will need to make adjustments, and in the case of heavy persistent swap it might be zswap is better or it might be that nothing can help that workload except buying more RAM. > What almost noone wrote about is CPU usage, for which I saw two > anecdotal references: "no change" and "doubled CPU usage". For sure there is an impact on CPU. This exchanges IO bound work, for CPU and memory bound work. But it's pretty lightweight compression. And again, whatever is defined as "too much" CPU hit for the workload, necessarily translates into either "suffer the cost of IO bound swap-on-drive, or suffer the cost of more memory." There is no free lunch. It really isn't magic. One thing this might alter the calculus of is swappiness. Because the zram device is so much faster, page out page in is a lower penalty than file reclaim reads. So now instead of folks thinking swappiness should be 1 (or even 0), it's the opposite. It probably should be 100. See the swappiness section in the Chris Down article referenced in the proposal: https://chrisdown.name/2018/01/02/in-defence-of-swap.html > > It would be interesting to see a comparison of swap, compressed swap and > zram swap performance while having processes competing on swap. > E.g. System with 8 GB RAM: > * 2 processes with 3.5 GB memory each > this would leave about 1GB for the system itself, so with disk swap > there should be not much swapping and with zram swap I'd expect little > swapping too. > * 2 processes with 4 GB memory each > this would force light disk swap usage in the first two cases, I'm not > really sure what it would do to zram swap. > * 2 processes with 4.5 GB memory each > this would definitely lead to constant swapping, but it should still > fit in zram swap, with a ratio of 2:1 it should theoretically fit in a > 2GB zram device, and realistically in a 4GB zram device. I'm not sure. Maybe. But this is the plus of having it available and folks testing it. It is still as rudimentary as swap. It might be useful to make it a bit smarter, look into some of the cgroupsv2 resource control work for hints on how to make the zram device bigger or smaller. Some workloads might favor a zram device sized to 100% RAM, without difficulty. > For the programs I'd think of something allocating memory and > writing/reading random parts of it, running for N iterations. > Interesting points would be: average CPU usage and wallclock time for > each of the processes. > > I've left out the obvious cases of "not enough memory usage to use any > of those anyway" and "too much memory usage that it results in oom". > oom killer should not invoke in daily usage anyway, I see that as a sign > for "something has gone seriously wrong", comparable with "program > segfaults on start". There are worse things than OOM. Stuck with a totally unresponsive system and no OOM on the way. Hence earlyoom. And on-going resource control work with cgroupsv2 isolation. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 6, 2020 at 10:04 AM Richard W.M. Jones wrote: > > On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: > > This laptop with 8GiB RAM is running two VMs at the same time: Windows > > 10 and Fedora Workstation 32. The host is Fedora Workstation 32. > > So this suggests another interesting question: If I have Fedora > virtual machines running on a Fedora host, and both are using zram, > could there be some negative interaction? ie. With the pages not > being compressible twice. I suppose (without looking at the source) > that zram will skip compressing a page if the compressed page is not > any smaller? I've not seen a negative interaction. But I am not a scientific sample :D However, it's surely true that compressed pages in the guest VM "memory" would not compress again in the host if those same pages are subject to eviction. Thus, two consequences: - the host 'zramctl' statistics will show lower compression ratio, as this type of eviction happens. - it might be an example workload where the host is better off with zswap, which is intended to work with swap-on-drive. (not part of this proposal). But also the zram devices are still pretty small so the negative effects are limited. Of course this gets tricky anytime there's significant overcommit of memory no matter the swap scheme. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 6, 2020 at 10:00 AM Richard W.M. Jones wrote: > > But let's say we also add a lower priority disk swap, then my next > question ... > > > > Also does the swap partition on disk contain compressed pages, or > > > uncompressed pages, or a mix of both? > > > > With zram there is no partition on disk, or was this question about > > something else? > > ... means: Does this secondary swap partition (on disk) contain > swapped out zram pages? Or uncompressed pages? (Or maybe the > question just makes no sense, I don't really know.) (ZRAM) Compression is intrinsic to just the /dev/zram device. The swap code doesn't share pages between swap devices. The higher priority device is favored first until full. Once full, pages don't go through the zram module, thus are not compressed, on their way to the swap-on-disk. (ZSWAP) So yeah, the swap-on-disk scenario might be better suited to a generator that could use zswap instead, which uses an existing swap partition and adds a write back cache (zpool) rather than a separate device. I'm pretty sure (not 100%) that cached page are decompressed on their way to the swap device. Also, the zpool memory cache is preallocated, unlike zram devices. (I am not going to envy any who decide to implement zswap on a system with ZFS. Wait wait wait, which zpool are you talking about?!) > > > > Also what is the compression algorithm? zlib or zstd or something > > > else? > > > > zramctl shows ALGORITHM > > > > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > > /dev/zram0 lzo-rle 11.7G 4K 74B 12K 8 [SWAP] > > > > So it is lzo-rle by default, but it should be possible to override this > > algorithm. There is an RFE for this already at zram-generator github. > > Interesting, thanks. It looks like zstd is an alternative, although I > don't know which will be better/faster. > > Rich. > > -- > Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones > Read my programming and virtualization blog: http://rwmj.wordpress.com > virt-top is 'top' for virtual machines. Tiny program with many > powerful monitoring features, net stats, disk stats, logging, etc. > http://people.redhat.com/~rjones/virt-top > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 9:27 AM, Richard W.M. Jones wrote: On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: See, this is a clear indication that you don't understand what it is doing and weren't listening to the various people trying to explain it. Not sure this is needed. The conversation so far has talked about many interesting topics which aren't covered in the proposal, and I value the opinions of people running server / other desktop loads. Sure, but the problem is that he keeps making incorrect claims about it and saying how bad it is and that it shouldn't be used even though multiple people have repeatedly explained that it doesn't work the way he thinks it does. Overall, this has been a great thread. I've now learned how zram works, I've tried it out, and I won't be turning it off. :-) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 10:41 AM, John M. Harris Jr wrote: On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: On 6/6/20 12:42 AM, John M. Harris Jr wrote: On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why you had problems with it, but it's working on fine on every system I've tried it on. It's not increasing my CPU usage. It's probably actually lower due to less swap thrashing. There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my 8 GiB of swap. This is most likely the case for most casual users, those not compiling complex software on their system. This is with Firefox, Konversation, KMail, virt-manager and a few Konsole sessions open. Great, then it probably wouldn't benefit you, but it also would not harm you at all either. In my case, my laptop was constantly thrashing the swap and now it isn't, so I'm very happy about it. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 9:04 AM, Richard W.M. Jones wrote: On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: This laptop with 8GiB RAM is running two VMs at the same time: Windows 10 and Fedora Workstation 32. The host is Fedora Workstation 32. So this suggests another interesting question: If I have Fedora virtual machines running on a Fedora host, and both are using zram, could there be some negative interaction? ie. With the pages not being compressible twice. I suppose (without looking at the source) that zram will skip compressing a page if the compressed page is not any smaller? I considered this as well. But that would only be a concern if the live memory of the VM is getting swapped out. Is that something that could happen? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Saturday, June 6, 2020 1:15:35 AM MST Samuel Sieb wrote: > On 6/6/20 12:42 AM, John M. Harris Jr wrote: > > > On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, > > enabling swap on zram led to increased CPU usage (Always above 13% where > > normally idling at 6%!), and my entire system freezing after about 30 > > minutes. In all fairness, I don't know why my system froze, as I couldn't > > get anything over netconsole and sysrq wasn't working, but I think I'm > > going to leave it disabled. Swap on disk is more than fast enough for > > buffer/cache and hibernation/resume on my system. > > > I don't know why you had problems with it, but it's working on fine on > every system I've tried it on. It's not increasing my CPU usage. It's > probably actually lower due to less swap thrashing. There wasn't any thrashing to begin with. I'm currently using 8.0Mi of my 8 GiB of swap. This is most likely the case for most casual users, those not compiling complex software on their system. This is with Firefox, Konversation, KMail, virt-manager and a few Konsole sessions open. > > I don't know why people seem to be repeating what seems to be the result > > of a placebo, saying that their system "feels more responsive" with swap > > on zram. People seem to be forgetting why swap on zram came up to begin > > with, it has nothing to do with system "responsiveness", which wasn't an > > issue. It had to do with dealing with OOM. Swap on zram isn't even a > > solution to that, it just changes how specifically it affects systems. > > > See, this is a clear indication that you don't understand what it is > doing and weren't listening to the various people trying to explain it. > It is definitely not a placebo. I gave zram 5G out of the 12G I have > and my laptop is performing way better now. It's not thrashing the disk > (SSD) every time I switch desktops or windows. Due to the number and > size of applications I'm running, I normally have to close Thunderbird > when I want to run Chrome. But now I can start Chrome up with no > problem. I converted my running system with no reboots and I didn't > change anything else about how I'm using the laptop. > > # zramctl > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lz4 5G 5G 1.7G 1.8G 4 > > 5GB of swap space that normally would be on disk is now taking less than > 2G of RAM. Instead of the usual 6G in the disk swap, now I have less > than 2. > > > > For servers, swap is useful regardless of the amount of RAM. Swap is very > > nice for use as buffer/cache, and leaves space in RAM for whatever the > > server is running. For example, I always configure a 4 GiB swap partition > > on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 > > GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a > > bit different depending on the workload, but it sets a very nice starting > > point. > > Swap is never used as buffer or cache, that doesn't even make sense. > Buffer is storing data before writing it to disk and cache is keeping > hot data somewhere with fast access. Why do you use so much swap on > your servers? The linear correlation with RAM is an obsolete idea and > was only somewhat valid when memory sizes were smaller. If you're using > any significant fraction of that swap space, your server is in trouble. It's not used for kernel buffer/cache, that's correct. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Saturday, June 6, 2020 3:37:13 AM MST Igor Raits wrote: > On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote: > > > Igor Raits wrote: > > > > > The change says it will use 50% of user’s RAM size, but not more > > > than > > > 4G. > > > > > > > > But if the machine has only, say, 4 GiB of RAM, then the amount of > > extra RAM > > you get that way might not be sufficient to avoid OOM. > > > > > > > > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > > > > > > > Also -1 to adding something to the core system that is written in > > > > a > > > > language > > > > for which we do not even have dynamic linking support. Or even > > > > real > > > > static > > > > linking support, as opposed to packaging libraries as source > > > > code. > > > > > > > > > > > > This is not fair. It is a programming language that is safer than C > > > and > > > is already used by some projects that we ship. rpm-ostree, firefox, > > > librsvg2 and others. > > > > > > > > 1. librsvg2 and firefox are not really core system components. They > > are > >UI-related packages (an image processing library and a web > > browser), > >which is at least one layer higher. > > 2. rpm-ostree is only a core system component if you use an ostree- > > based > >installation. In the default Fedora system, it is not. > > 3. I think that it is a bad enough precedent that even these packages > > are > >using Rust. We do not have a reasonable way to package software > > written > >in Rust. Packaging libraries as source code is not reasonable in a > > binary > >distribution. (And yes, I was opposed to the Go packaging > > guidelines from > >day 1, and the Rust packaging guidelines copy the same broken > > concepts, > >so I am opposed to those as well.) As a result, shipping Rust > > software in > >Fedora is very painful, because everything is essentially > > statically > >linked (actually compiled on demand at application compile time > > and then > >statically linked into the application). > > > Why is it painful? You have all dependencies packaged that follow > semver (not like Go) and it is quite easy to build those packages. > > Another example here could be nodejs, even though it does not link > statically it is just PITA to package since ecosystem is just full of > very small libraries that do not really like to cooperate so you need > to have tens of different versions of a lib in a repo. I consider this > much bigger problem than the Rust has in Fedora. > > > > 4. The Rust toolchain is also inherently foreign on Fedora because it > > is not > >based on GCC (but on LLVM). > > > That way you can say that mesa is foreign because it uses LLVM. If > there is ever alternative compiler to Rust that is based on GCC and has > feature parity, we can definitely consider trying it out. But the > referene compiler works just well. > > > > > > > > Core system components should be written in C. The higher layers (UI, > > extra > > CLI tools, etc.) can use C++ as well. IMHO, any other programming > > language > > is just a pain. > > > We also have Fedora CoreOS that uses > https://github.com/coreos/afterburn and > https://github.com/coreos/zincati that are written in Rust as well and > those are core system utilities. Sure, but Fedora CoreOS is not Fedora. Err, not Fedora, the distro. This is yet another example of how throwing all of these toys under the Fedora umbrella can sound confusing. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: > See, this is a clear indication that you don't understand what it is > doing and weren't listening to the various people trying to explain > it. Not sure this is needed. The conversation so far has talked about many interesting topics which aren't covered in the proposal, and I value the opinions of people running server / other desktop loads. (This is without any opinion on whether zram is good or bad - I hadn't heard about it before, haven't used it, but the technology looks interesting.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Fri, Jun 05, 2020 at 04:07:44PM -0600, Chris Murphy wrote: > This laptop with 8GiB RAM is running two VMs at the same time: Windows > 10 and Fedora Workstation 32. The host is Fedora Workstation 32. So this suggests another interesting question: If I have Fedora virtual machines running on a Fedora host, and both are using zram, could there be some negative interaction? ie. With the pages not being compressible twice. I suppose (without looking at the source) that zram will skip compressing a page if the compressed page is not any smaller? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Fri, Jun 05, 2020 at 05:55:26PM +0200, Igor Raits wrote: > On Fri, 2020-06-05 at 15:11 +0100, Richard W.M. Jones wrote: > > I'm unclear: that ~50M is still in RAM? Or it's compressed on a disk > > somewhere? > > IIUC, it takes some part of the RAM and just compresses it on the fly. > For example, I have 32G memory on my laptop and when I enable zram > device, I basically have 23G listed in free as memory and 11G as the > swap. And that 11G is supposed to be compressed memory (in avg cases > with 2:1 ration). > > Of course, as part of this change, it will be made that it can't take > more than 4G no matter what by default. Thanks - the fact that the primary swap partition now lives in RAM is what I was missing. But let's say we also add a lower priority disk swap, then my next question ... > > Also does the swap partition on disk contain compressed pages, or > > uncompressed pages, or a mix of both? > > With zram there is no partition on disk, or was this question about > something else? ... means: Does this secondary swap partition (on disk) contain swapped out zram pages? Or uncompressed pages? (Or maybe the question just makes no sense, I don't really know.) > > Also what is the compression algorithm? zlib or zstd or something > > else? > > zramctl shows ALGORITHM > > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > /dev/zram0 lzo-rle 11.7G 4K 74B 12K 8 [SWAP] > > So it is lzo-rle by default, but it should be possible to override this > algorithm. There is an RFE for this already at zram-generator github. Interesting, thanks. It looks like zstd is an alternative, although I don't know which will be better/faster. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Le samedi 06 juin 2020 à 12:37 +0200, Igor Raits a écrit : > > Why is it painful? You have all dependencies packaged that follow > semver (not like Go) and it is quite easy to build those packages. And Go has all build dependencies in the release where they are used (not like rust, with magic ephemeral rawhide-only packages) See? Easy to find faults in other people’s work -- Nicolas Mailhot ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:09 +0200, Kevin Kofler wrote: > Igor Raits wrote: > > The change says it will use 50% of user’s RAM size, but not more > > than > > 4G. > > But if the machine has only, say, 4 GiB of RAM, then the amount of > extra RAM > you get that way might not be sufficient to avoid OOM. > > > On Fri, 2020-06-05 at 08:54 +0200, Kevin Kofler wrote: > > > Also -1 to adding something to the core system that is written in > > > a > > > language > > > for which we do not even have dynamic linking support. Or even > > > real > > > static > > > linking support, as opposed to packaging libraries as source > > > code. > > > > This is not fair. It is a programming language that is safer than C > > and > > is already used by some projects that we ship. rpm-ostree, firefox, > > librsvg2 and others. > > 1. librsvg2 and firefox are not really core system components. They > are > UI-related packages (an image processing library and a web > browser), > which is at least one layer higher. > 2. rpm-ostree is only a core system component if you use an ostree- > based > installation. In the default Fedora system, it is not. > 3. I think that it is a bad enough precedent that even these packages > are > using Rust. We do not have a reasonable way to package software > written > in Rust. Packaging libraries as source code is not reasonable in a > binary > distribution. (And yes, I was opposed to the Go packaging > guidelines from > day 1, and the Rust packaging guidelines copy the same broken > concepts, > so I am opposed to those as well.) As a result, shipping Rust > software in > Fedora is very painful, because everything is essentially > statically > linked (actually compiled on demand at application compile time > and then > statically linked into the application). Why is it painful? You have all dependencies packaged that follow semver (not like Go) and it is quite easy to build those packages. Another example here could be nodejs, even though it does not link statically it is just PITA to package since ecosystem is just full of very small libraries that do not really like to cooperate so you need to have tens of different versions of a lib in a repo. I consider this much bigger problem than the Rust has in Fedora. > 4. The Rust toolchain is also inherently foreign on Fedora because it > is not > based on GCC (but on LLVM). That way you can say that mesa is foreign because it uses LLVM. If there is ever alternative compiler to Rust that is based on GCC and has feature parity, we can definitely consider trying it out. But the referene compiler works just well. > > Core system components should be written in C. The higher layers (UI, > extra > CLI tools, etc.) can use C++ as well. IMHO, any other programming > language > is just a pain. We also have Fedora CoreOS that uses https://github.com/coreos/afterburn and https://github.com/coreos/zincati that are written in Rust as well and those are core system utilities. I don't think saying "Ditch Python, Ruby, Perl, … from the system components" is useful for anyone since you know that it is not going to happen. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcdkACgkQEV1auJxc Hh6Aqg//bbeyDzTLPVhN41P7TU5LeA2d1c/Ya2tjbpvWf3VaWsJ26UDdLUyIXw2c r4/C3Kkda7qGHmOSjLRlBvzEMe3e7wO+Xi+16ZyTex6+2M1bxifAXZHTz1wtkhIW AmdMvyjJbCrzc3jUG3dj3FfE4PWjS58tZYIvG8XEcRxoyvWOsMRqdaxP0V9Frhr7 9hxULUenGpVzvXz+z8/s7rosN4yqTotv1HCFRCworHhXXErVzEy8ha7EjZpGwnyL zDssJ0jB+5eMYk94J2NG5ZwBkOSxBfYMEO4dDLQdMPk6jBEfpZg1jS5wIkbUx3UR fZpitoOs5snIyh46bjL5ldod9lgJ+j7txSle0tpTbeGsPRqVIq+k7NhRI7s24q+R uaJwHDsGRtBaWeTzzykCPlj7kRh/y/fV3TIBzpi5apK1aXxmAZw/RuMXzZK65yFb cGQ79jKanOzRMCD97T+ExiBNpk5Oj0dEF3dWlbHAxoHDc5UFRxyizUPPUNGHooTg qmnssso/a4MoS0/IdTsHpJP62Xm7tGBm9VfIDkK9GFxBZ+L5nj/43yuBxKUMA2s/ pWBZ2FiqzLQ0RyD1IqXsUVyoxm3X66FRywkTgUdg56MQAvZQkppdeoBwoP4kBOdS Yqnt/GC3iq0bt+7Rt7TQudB5fXOKnFL7oGyrx6zAoct3n+F+HNk= =H4dJ -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, 2020-06-06 at 02:19 +0200, Kevin Kofler wrote: > Chris Murphy wrote: > > So yes it's well suited for these cases and the proposal does > > include > > them. If they wish to be left out, that's up to those working > > groups. > > It's possible to make sure /etc/systemd/zram-generator is not > > present. > > Also, why does this have to be a systemd generator? As a user > administrating > his own systems, I find those to be extremely annoying, because they > do > stuff behind my back that I never asked to happen and I have to mask > them > (and/or uninstall them completely) to get rid of the unwanted > behavior. > > E.g., the systemd generator that tries to automount partitions not > listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap > partition > I have on my SSD in case I ever need it, which is normally NOT > mounted to > avoid wearing out the SSD). So why does systemd want to second-guess > me and > mount that partition behind my back unless I go out of my way to mask > the > magic generator? > > So why can this zram feature not be a line in fstab, a parameter > passed > through the kernel CLI, or some other solution that is easily > tweakable and > that will definitely not affect upgrades of existing installations > (unlike > yet another systemd generator, if it happens to get installed for > whatever > reason)? > > IMHO, the only systemd generator that should ever mount partitions of > any > kind (including virtual ones such as zram) is the systemd-fstab- > generator. > If you want more stuff mounted, it should be added to /etc/fstab, > that's > what that file is for! Well, with systemd.mount it is already possible to mount things that are not in /etc/fstab. That file has same disadvantages as any other configuration files in «unstructured» format. You can't override some specific setting of it, disable some mount by simple command (that is not sed) and so on. Also if AIUI, it is not trivial to make it work with just fstab because something has to create a swap during the boot and fstab entry clearly can't do that. > Kevin Kofler > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7bcA8ACgkQEV1auJxc Hh5VGA//SNQOQdLoTvqZKdfS9DpPSsvh/Lii/FMe38viOmy6hcAjQJ6Z3PlJX9cb e/4i8af/OTzYkoYLQLlRwOfXszcZvKCEtjAJz3yfOTOxwxuItucsC7HeuMXiDlpG 3RuV2yLoZFOo+BwlfjFLxvNZRag+w8GLuSLFO0Nes1xjZMNwoI31PVyIykZ60YsH LX7vPZ80QOKAQHpPuxChyOIH0uXelGN8Mnl7lVu9jPPaDQaCzbUpcSBTeiNK0MGK oUFMXB0zfTZqk0iLI3VVdf3MZl2hro9R4c3AkbDsitcFwlWoMuM07U8jdNvuf0pP Zlm5hnZ/Xks3RzC+6wsIqB//ubS5f6WYLt4B/tH4zhAyW2CIxcWx3n9eonLshFX+ QqS92HuS/KBfcVG5GCpAMVwBdZwikjxbnf0CQ0az34iae2FmKwyVc2jKOwwdwCke eGnMeo623p4uuLC+R9LwjQCAK8BHi6dQqRgY+Ybp6ymzPpffqaWzENxRmGeG/0M3 cNjrsHQlKvxnXhbbungeJIEPVFXn4Y/V1sXOrj5JMW/M9Dk44M3lrATiiiojZDxA tRsKgtGKzT4WTp67N4/dnK61ByCDAew39IG8JFUr/2dUDoDkEpXk4mSxcU3K7kln +yagnUD6UTTeWWtq76nKer9ydjrN/tdi9yVfHGFXqbKboFKQ/ok= =rfaN -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Hi! On Sat, Jun 06, 2020 at 01:15:35AM -0700, Samuel Sieb wrote: > 5GB of swap space that normally would be on disk is now taking less than 2G > of RAM. Instead of the usual 6G in the disk swap, now I have less than 2. What's bugging me about this thread is that quite a few people made comparisions resulting in "compressed zram is smaller than uncompressed disk swap". For me this seems quite obvious, and looks like flawed testing. Wouldn't it be more correct to also compress disk swap to compare size? This would probably make the size-argument void, as I'd expect them to be the same size. If it's not, that would be an useful data point. Also I don't care about 10GB stuff sitting in disk swap, whilst 1GB of RAM could be quite essential. This leaves overall performance as a potential benefit of zram swap. What almost noone wrote about is CPU usage, for which I saw two anecdotal references: "no change" and "doubled CPU usage". It would be interesting to see a comparison of swap, compressed swap and zram swap performance while having processes competing on swap. E.g. System with 8 GB RAM: * 2 processes with 3.5 GB memory each this would leave about 1GB for the system itself, so with disk swap there should be not much swapping and with zram swap I'd expect little swapping too. * 2 processes with 4 GB memory each this would force light disk swap usage in the first two cases, I'm not really sure what it would do to zram swap. * 2 processes with 4.5 GB memory each this would definitely lead to constant swapping, but it should still fit in zram swap, with a ratio of 2:1 it should theoretically fit in a 2GB zram device, and realistically in a 4GB zram device. For the programs I'd think of something allocating memory and writing/reading random parts of it, running for N iterations. Interesting points would be: average CPU usage and wallclock time for each of the processes. I've left out the obvious cases of "not enough memory usage to use any of those anyway" and "too much memory usage that it results in oom". oom killer should not invoke in daily usage anyway, I see that as a sign for "something has gone seriously wrong", comparable with "program segfaults on start". All the best, David signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Kevin Kofler wrote: > with two 3 GiB HDDs Correction: two 3 TB HDDs. That was off by a factor 931. :-) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
Samuel Sieb wrote: > See, this is a clear indication that you don't understand what it is > doing and weren't listening to the various people trying to explain it. > It is definitely not a placebo. I gave zram 5G out of the 12G I have > and my laptop is performing way better now. It's not thrashing the disk > (SSD) every time I switch desktops or windows. If you are always running out of RAM with 12 GiB, you need to look into the applications you are running. I have a notebook with 4 GiB RAM and 8 GiB swap and it is usable with Fedora (KDE Spin), Plasma, and some applications. Are you running only standard desktop applications or some memory-intensive simulations or something? > Due to the number and size of applications I'm running, I normally have to > close Thunderbird when I want to run Chrome. But now I can start Chrome > up with no problem. Wow. I am running Trojitá (IMAP mail) and Falkon (web browser) right now, plus Konversation (IRC) and KNode (NNTP, in which I am writing this message right now), and KSensors reports 2096 MiB of RAM and 0 MiB of swap used. So what is using so much RAM? Are Thunderbird and Chrome so memory-hungry or is it the other applications you are running? (Which ones?) > Swap is never used as buffer or cache, that doesn't even make sense. > Buffer is storing data before writing it to disk and cache is keeping > hot data somewhere with fast access. Why do you use so much swap on > your servers? The linear correlation with RAM is an obsolete idea and > was only somewhat valid when memory sizes were smaller. If you're using > any significant fraction of that swap space, your server is in trouble. He actually has much less swap set up than I do. Not even half his RAM. I just stick to twice the RAM, because taking 16 GiB away from a 3 TB RAID1 to make room for a 32 GiB RAID0 swap is not going to make any practical difference. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
John M. Harris Jr wrote: > On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, > enabling swap on zram led to increased CPU usage (Always above 13% where > normally idling at 6%!), and my entire system freezing after about 30 > minutes. In all fairness, I don't know why my system froze, as I couldn't > get anything over netconsole and sysrq wasn't working, but I think I'm > going to leave it disabled. Swap on disk is more than fast enough for > buffer/cache and hibernation/resume on my system. You actually made another point there, between the lines: hibernation/resume is actually never going to work with zram, by design. You cannot hibernate to something that is no more persistent than the RAM (because it is actually just a compressed virtual disk within that exact same RAM). > For servers, swap is useful regardless of the amount of RAM. Swap is very > nice for use as buffer/cache, and leaves space in RAM for whatever the > server is running. For example, I always configure a 4 GiB swap partition > on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 > GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit > different depending on the workload, but it sets a very nice starting > point. I actually created 32 GiB of swap on my desktop with 16 GiB of RAM. Twice the RAM, as used to be the norm. Though admittedly, much of it sits unused all the time, and most of the time, the usage is even at 0 altogether. But with two 3 GiB HDDs, there is plenty of space for a small swap RAID0 next to the data RAID1. (I care about long-term data integrity for the actual data, not for swap, which is throwaway content by definition.) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/6/20 12:42 AM, John M. Harris Jr wrote: On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why you had problems with it, but it's working on fine on every system I've tried it on. It's not increasing my CPU usage. It's probably actually lower due to less swap thrashing. I don't know why people seem to be repeating what seems to be the result of a placebo, saying that their system "feels more responsive" with swap on zram. People seem to be forgetting why swap on zram came up to begin with, it has nothing to do with system "responsiveness", which wasn't an issue. It had to do with dealing with OOM. Swap on zram isn't even a solution to that, it just changes how specifically it affects systems. See, this is a clear indication that you don't understand what it is doing and weren't listening to the various people trying to explain it. It is definitely not a placebo. I gave zram 5G out of the 12G I have and my laptop is performing way better now. It's not thrashing the disk (SSD) every time I switch desktops or windows. Due to the number and size of applications I'm running, I normally have to close Thunderbird when I want to run Chrome. But now I can start Chrome up with no problem. I converted my running system with no reboots and I didn't change anything else about how I'm using the laptop. # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 5G 5G 1.7G 1.8G 4 5GB of swap space that normally would be on disk is now taking less than 2G of RAM. Instead of the usual 6G in the disk swap, now I have less than 2. For servers, swap is useful regardless of the amount of RAM. Swap is very nice for use as buffer/cache, and leaves space in RAM for whatever the server is running. For example, I always configure a 4 GiB swap partition on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit different depending on the workload, but it sets a very nice starting point. Swap is never used as buffer or cache, that doesn't even make sense. Buffer is storing data before writing it to disk and cache is keeping hot data somewhere with fast access. Why do you use so much swap on your servers? The linear correlation with RAM is an obsolete idea and was only somewhat valid when memory sizes were smaller. If you're using any significant fraction of that swap space, your server is in trouble. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Friday, June 5, 2020 11:57:50 PM MST Samuel Sieb wrote: > On 6/5/20 11:43 PM, John M. Harris Jr wrote: > > > Completely agreed, going about it this way would also address most of my > > concerns with this change, as it would mean it's easy for people like > > myself to opt out. > > > If you don't want it, then disable the generator or uninstall it. I > don't understand why you're so against this. It's not even really new. > Is it because you don't understand it? Try it, you'll like it. It made > such a big difference on my laptop. I'm going to be activating it on my > other computers and servers as I get time. Most of the servers have > enough RAM to not need swap, but it makes a nice safety net with > virtually no overhead. On my laptop, a Lenovo X200T with Core(TM)2 Duo CPU U9300; 6 GiB RAM, enabling swap on zram led to increased CPU usage (Always above 13% where normally idling at 6%!), and my entire system freezing after about 30 minutes. In all fairness, I don't know why my system froze, as I couldn't get anything over netconsole and sysrq wasn't working, but I think I'm going to leave it disabled. Swap on disk is more than fast enough for buffer/cache and hibernation/resume on my system. I don't know why people seem to be repeating what seems to be the result of a placebo, saying that their system "feels more responsive" with swap on zram. People seem to be forgetting why swap on zram came up to begin with, it has nothing to do with system "responsiveness", which wasn't an issue. It had to do with dealing with OOM. Swap on zram isn't even a solution to that, it just changes how specifically it affects systems. For servers, swap is useful regardless of the amount of RAM. Swap is very nice for use as buffer/cache, and leaves space in RAM for whatever the server is running. For example, I always configure a 4 GiB swap partition on servers with 8-24 GiB of RAM, and 8 GiB swap for servers with 64-128 GiB, 16 GiB on servers with 128-256 GiB, etc. Beyond that, tuning is a bit different depending on the workload, but it sets a very nice starting point. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/5/20 11:43 PM, John M. Harris Jr wrote: Completely agreed, going about it this way would also address most of my concerns with this change, as it would mean it's easy for people like myself to opt out. If you don't want it, then disable the generator or uninstall it. I don't understand why you're so against this. It's not even really new. Is it because you don't understand it? Try it, you'll like it. It made such a big difference on my laptop. I'm going to be activating it on my other computers and servers as I get time. Most of the servers have enough RAM to not need swap, but it makes a nice safety net with virtually no overhead. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Friday, June 5, 2020 5:19:55 PM MST Kevin Kofler wrote: > Chris Murphy wrote: > > > So yes it's well suited for these cases and the proposal does include > > them. If they wish to be left out, that's up to those working groups. > > It's possible to make sure /etc/systemd/zram-generator is not present. > > > Also, why does this have to be a systemd generator? As a user administrating > his own systems, I find those to be extremely annoying, because they do > stuff behind my back that I never asked to happen and I have to mask them > (and/or uninstall them completely) to get rid of the unwanted behavior. > E.g., the systemd generator that tries to automount partitions not listed in > fstab based on their GPT UUIDs is just broken. If I do not have the > partition in the fstab, I left it out for a reason (e.g., the swap > partition I have on my SSD in case I ever need it, which is normally NOT > mounted to avoid wearing out the SSD). So why does systemd want to > second-guess me and mount that partition behind my back unless I go out of > my way to mask the magic generator? > > So why can this zram feature not be a line in fstab, a parameter passed > through the kernel CLI, or some other solution that is easily tweakable and > that will definitely not affect upgrades of existing installations > (unlike yet another systemd generator, if it happens to get installed for > whatever reason)? > > IMHO, the only systemd generator that should ever mount partitions of any > kind (including virtual ones such as zram) is the systemd-fstab-generator. > If you want more stuff mounted, it should be added to /etc/fstab, that's > what that file is for! Completely agreed, going about it this way would also address most of my concerns with this change, as it would mean it's easy for people like myself to opt out. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Fri, Jun 5, 2020 at 8:33 PM Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote: > > > > >> # swapon > > >> NAME TYPE SIZE USED PRIO > > >> /dev/sda3 partition 16G 1.9G-2 > > >> /zram0partition 4G 4G 32767 > > >> > > >> This looks like I'm using all 4G of allocated space in the zram swap, > > >> but: > > >> > > >> # zramctl > > >> NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > > >> /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 > > >> > > >> This suggests that it's only using 1.8G. Can you explain what this > > >> means? > > > > > > Yeah that's confusing. zramctl just gets info from sysfs, but you > > > could double check it by > > > > > > cat /sys/block/zram0/mm_stat > > > > > > The first value should match "DATA" column in zramctl (which reports in > > > MiB). > > > > > > While the kernel has long had support for using up to 32 swap devices > > > at the same time, this is seldom used in practice so it could be an > > > artifact of this? Indicating that all of this swap is "in use" from > > > the swap perspective, where zramctl is telling you the truth about > > > what the zram kernel module is actually using. Is it a cosmetic > > > reporting bug or intentional? Good question. I'll try to reproduce and > > > report it upstream and see what they say. But if you beat me to it > > > that would be great, and then I can just write the email for linux-mm > > > and cite your bug report. :D > > > > Part of my concern is that if it's not actually full, then why is it > > using so much of the disk swap? OK I can't explain what you're seeing because I'm not certain of the workload. Here's what I've got going on. F32, 5.7.0-fc33 kernel, 8G RAM, 4G swaponzram, 10G swapondrive. With swaponzram higher priority before doing any swapping. $ free -m totalusedfree shared buff/cache available Mem: 786413954251 6022166122 Swap: 14559 0 14559 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 0B -2 /dev/zram0 partition 3.9G 0B3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 4K 74B 12K 8 [SWAP] Then build webkitgtk using 'ninja -j10' What happens? Only the swaponzram0 is used for a while. It fills up and then swaponsda5 starts being used. But also, the used on swapzram0 goes down and up and down and up. During this time, swaponsda5 mostly doesn't change. Sometimes it goes down. But it only goes back up again if swaponzram0 is already full. I think this is working as I expect because once anonymous pages are in either swap, they don't migrate between the swaps. But anonymous pages can always be deallocated from either swap at any time leading to the appearance that zram0 isn't being used to the max - well because it's not. Here is an example. $ free -m totalusedfree shared buff/cache available Mem: 786456131945 63 3051929 Swap: 1455947459814 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 1.9G -2 /dev/zram0 partition 3.9G 2.6G3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 2.4G 582.1M 877.6M 8 [SWAP] $ The gap between COMPR and TOTAL might seem big. And in fact it might be fragmentation not metadata overhead, as was earlier suggested. But it changes a lot and fast with this workload. Just a couple minutes later. $ free -m totalusedfree shared buff/cache available Mem: 78647602 125 1 136 56 Swap: 1455973427216 $ swapon NAME TYPE SIZE USED PRIO /dev/sda5 partition 10.4G 3.4G -2 /dev/zram0 partition 3.9G 3.9G3 $ zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lzo-rle 3.9G 3.9G 913.1M 954M 8 [SWAP] $ I'm getting 4:1 compression ratio with this workload, by the way. It's so far not using more than 1GiB RAM to save me 4G. Or a net savings of 3G that is regular memory. But more importantly than the compression? The fact 4GiB did not need to page out and back in from SSD. And in fact as the workload progresses, it's saving quite a lot more than 4G of pageouts to disk - I just don't have a cumulative value. Also? The workload has a high wait state for CPU when it's IO bound, waiting on the drive, even though it's an SSD. The zram based swap is only as smart as the workload is at properly deallocating things that it no longer needs. If it's holding onto anonymous pages and they're in the swap-on-zram device, then that's it, back to disk swapping only. I haven't yet seen swapon claim swap was full but then zramctl say it wasn't.
Re: Fedora 33 System-Wide Change proposal: swap on zram
On 6/5/20 7:33 PM, Chris Murphy wrote: On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote: All three of those listed provide competing configurations for swap on zram. Just to make a fine point, zram is generic, it is not swap specific. It's just a compressed ram disk. Zswap is a different thing, it is swap specific, providing a memory based writeback cache to a disk based swap. Ok, that makes sense about zram. It's a lot simpler than I was thinking it was. The generator does require a reboot to change configurations. You could absolutely say, but Chris, the other ones you can just systemctl restart! That is true, but except for testing, I don't see that as an advantage compared to the overall simplisticity of zram-generator and reusing the existing infrastructure in systemd that's already well tested and maintained. Sure, I'll set that up for the next time I reboot. But that is likely to still be a long time from now. Although really any value higher than the disk based swap is sufficient. The systemd-swap service appears to set the priority of zram to the maximum possible. No, it was quite clear that I was modifying the right config. It's the /etc/systemd/swap.conf as described in the man page and it was affecting the result. OK that is not for zram-generator. That's for one of the others. Off hand I don't know which one it's for, this is way too confusing because of all the competing implementations, which is part of the motivation of the feature -> buh bye, thank you for your service! Sorry, I guess that wasn't clear. That's the config file for systemd-swap which is what I was testing. Part of my concern is that if it's not actually full, then why is it using so much of the disk swap? Not sure. What should be true is if you swapoff on /dev/sda3 it'll move any referenced anon pages to /dev/zram0. And then if you swapon /dev/sda3 it will use 0 bytes until /dev/zram0 is full. What kernel version are you using? That is what I did do. kernel 5.5.17-200.fc31.x86_64 For upstream, do you mean the kernel? Yes. bugzilla.kernel.org - this goes to the linux-mm folks (memory management) but you can search for a zram bug and just see what component they use and post the bug here and I'll pick it up. I reset everything and now I can't reproduce it. I wonder if it was because I had zswap enabled as well. When I was going to file the bug report, I came across a comment that it's not beneficial to use them both at the same time. # swapon NAME TYPE SIZE USED PRIO /dev/sda3 partition 16G 0B-2 /zram0partition 5G 4.6G 32767 # zramctl NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 lz4 5G 4.6G 1.5G 1.5G 4 It looks like it's working properly now. So it seems likely that it was user error. And for the little it matters, I approve of the change proposal. I will have to test it out on my other systems as well now. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: swap on zram
On Fri, Jun 5, 2020 at 8:12 PM Samuel Sieb wrote: > > On 6/5/20 6:59 PM, Chris Murphy wrote: > > On Fri, Jun 5, 2020 at 6:47 PM Samuel Sieb wrote: > >> > >> I installed the zram package and noticed the systemd-swap package, so > >> installed that also. > > > > There are conflicting implementations: > > > > anaconda package provides zram.service > > zram package provides zram-swap.service > > systemd-swap package provides > > Did you leave something out? systemd-swap package provides systemd-swap.service > Are you saying that zram and systemd-swap both provide configuration for > zram? All three of those listed provide competing configurations for swap on zram. Just to make a fine point, zram is generic, it is not swap specific. It's just a compressed ram disk. Zswap is a different thing, it is swap specific, providing a memory based writeback cache to a disk based swap. > > > I've only casually tested systemd-swap package. Note this isn't an > > upstream systemd project. Where as the proposed rust zram-generator is > > "upstream" in that it's maintained by the same folks, but is not > > provided by systemd package I think because it's in rust. > > Ok, I was thinking the generator might require rebooting to get it to > work. And I saw the systemd-swap package and thought that sounded > useful to try. The generator does require a reboot to change configurations. You could absolutely say, but Chris, the other ones you can just systemctl restart! That is true, but except for testing, I don't see that as an advantage compared to the overall simplisticity of zram-generator and reusing the existing infrastructure in systemd that's already well tested and maintained. > > > There shouldn't be any weird/bad interactions between them, but it is > > possible for the user to become very confused which one is working. It > > *should* be zram-generator because it runs much earlier during boot > > than the others. But I have not thoroughly tested for conflicting > > interactions, mainly just sanity testing to make sure things don't > > blow up. > > I only started the one service, so I don't think there are any conflicts. So what you can do is disable all the above listed service units. And you'll be testing the zram-generator alone. The config file for that is /etc/systemd/zram-generator.conf Since there isn't yet an option to set swap priority, chances are it gets auto-assigned during boot by the kernel. Usually /dev/zram0 comes first and should get -2 priority and /dev/swapondisk will get a -3. In that case, zram is higher priority already. But if flipped, you can just: swapoff /dev/zram0 swapon -p 3000 /dev/zram0 Although really any value higher than the disk based swap is sufficient. > > >> I adjusted the zram setting to 4G and reduced > >> zswap a bit. I have no idea what that is doing, it doesn't seem to > >> affect anything I can measure. The overall improvement in > >> responsiveness is very nice. > > > > It might be you're modifying the configuration of a different > > implementation from the one that's actually setting up swaponzram. > > No, it was quite clear that I was modifying the right config. It's the > /etc/systemd/swap.conf as described in the man page and it was affecting > the result. OK that is not for zram-generator. That's for one of the others. Off hand I don't know which one it's for, this is way too confusing because of all the competing implementations, which is part of the motivation of the feature -> buh bye, thank you for your service! > > >> I don't understand the numbers I'm getting for these. I disabled my > >> swap partition to force as much to go to zram as possible and then > >> turned it back on. > >> > >> # swapon > >> NAME TYPE SIZE USED PRIO > >> /dev/sda3 partition 16G 1.9G-2 > >> /zram0partition 4G 4G 32767 > >> > >> This looks like I'm using all 4G of allocated space in the zram swap, but: > >> > >> # zramctl > >> NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > >> /dev/zram0 lz4 4G 1.8G 658.5M 679.6M 4 > >> > >> This suggests that it's only using 1.8G. Can you explain what this means? > > > > Yeah that's confusing. zramctl just gets info from sysfs, but you > > could double check it by > > > > cat /sys/block/zram0/mm_stat > > > > The first value should match "DATA" column in zramctl (which reports in > > MiB). > > > > While the kernel has long had support for using up to 32 swap devices > > at the same time, this is seldom used in practice so it could be an > > artifact of this? Indicating that all of this swap is "in use" from > > the swap perspective, where zramctl is telling you the truth about > > what the zram kernel module is actually using. Is it a cosmetic > > reporting bug or intentional? Good question. I'll try to reproduce and > > report it upstream and see what they say. But if you beat me to it > > that would be great, and then I can just write the email for linux-mm > >
