Re: swap-on-ZRAM by default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 2020-06-07 at 18:19 -0600, Chris Murphy wrote:
> On Sun, Jun 7, 2020 at 12:56 PM Konstantin Kharlamov <
> hi-angel@xxxxxxxxx> wrote:
> > Hello! I see a proposal to enable zram by deafult¹. If I correctly
> > understand this is the thread where it's being discussed. I have a
> > few
> > questions, answers to which probably would be nice to add to the
> > proposal.
> >
> > 1. It says ZRAM gets enabled on upgrade. What's gonna happen to
> > systems
> > with ZSWAP is enabled? I guess it doesn't make sense to keep them
> > both.
>
> Good question! I will add this to the feedback section.
>
> - there is no immediate conflict between them, system will boot
> normally and there will be no errors in the journal
> - since you've already decided to dedicate X% to zswap's cache, which
> is a preallocation, the feature does intervene in your preferred
> setup
> by favoring the swaponzram first, before the workload hits zswap. And
> only if it fills up the zram device first.
>
> My recommendation?
>
> rm /etc/systemd/zram-generator.conf
>
> That will disable this feature.

Thanks! While it's great there's a manual solution, I'd expect there's
a big percent of users who would not know about upcoming enabling of
ZRAM. Should there be some automatic decision? For example, either
disabling ZSWAP or disabling ZRAM? Or perhaps popping up a warning on
upgrade where a user given a choice whether to disable one or another?

> > Let me emphasize that: 3GB of compressed RAM (ZSWAP + SWAP) is not
> > enough! The moral of this story is that you can't get away with
> > only
> > ZRAM without any disk SWAP. You need disk SWAP. And if you have
> > disk
> > SWAP, ZSWAP fits more nicely there as a compressing buffer before
> > the
> > data finally spills over to disk.
>
> Your use case is intentionally overcommitting available memory and it
> sounds like you don't have much choice in that you (a) the workload
> you have is the workload you need to run, and (b) memory isn't
> upgradeable.
>
> You should consider testing whether swap-on-zram sized to 100% RAM
> fits your use case better. And in fact if your workload gets very
> good
> compression ratios, it can be quite reasonable to go higher than
> 100%.

Thanks! I'll give it a try, will report back.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux