>75% and 6G >for the cap might be better. I agree. I think that 4GB cap is too small and 4 GB may be used quickly.
>I regularly see 3 to 1 and even 4 to 1. It's true. It's easy to get 4:1 with browser. In fact, the compression ratio is highly dependent on the workload. I get 1.4:1 with blender, and maybe 100:1 with compressing zeroes in tmpfs: https://imgur.com/a/XfNRedA пт, 10 июл. 2020 г. в 01:46, Chris Murphy <li...@colorremedies.com>: > On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr <joh...@splentity.com> > wrote: > > > What's the KDE SIG's rationale behind supporting this? This actively > limits > > the amount of RAM that end users are able to make use of. The more RAM > the end > > user has, the more RAM is not available for use, because EarlyOOM will > kill > > software long before it's able to be used. For example, on my system, > with 6 > > GiB of RAM, this will send SIGTERM while I still have over half of a > gigabyte > > of RAM, and SIGKILL while I still have over a quarter of a gigabyte of > RAM. > > 6G RAM means a 3G /dev/zram0 device that will use ~ 1.5G RAM *if* the > swap device is full and we're only getting 2 to 1 compression. 2 to 1 > is conservative I regularly see 3 to 1 and even 4 to 1. But let's go > with 2:1. This means your system has the effective benefit of running > 9G RAM at a cost of 1.5G. i.e a net of 7.5G RAM. Without having to use > disk based swap. > > Is it possible a case can be made for using zswap instead (this is not > related to zram at all - this is compressed memory cache that acts as > a writeback cache to an existing disk based swap)? Yes. I've made this > argument myself, so has Alexey. And as we learn more about those use > case and workloads, it is possible that it may be a future feature. > It's even possible it gets rolled into zram-generator so that users > don't have to fuss with these things. But in the meantime? We are > learning and innovating. And by all means try to break it. No one > wants users to have a suboptimal experience out of the box. > > My suggestion is to stop the 'complaining for the sake of complaining' > phase of the feature. And move to the "when I do X Y Z, this other app > is killed off - how to tweak this?" And then does the tweak represent > covering an edge case? Or is it good enough to be the new default? > > We can certainly change the defaults in the F33 cycle for both > swaponzram and earlyoom. In fact we can change the defaults with a > regular update if we have clear data that we should do that. But we've > entered the real world phase of testing. And the hypotheticals from > just complaining isn't very useful, even if those complaints later > turn out to be valid. Data is what will persuade. > > There's lots of data from Fedora IoT and other use cases out there > that 50% RAM for the /dev/zram size is a pretty good start. It's > likely it could go to 75% even in the Fedora 33 time frame. So folks > should really try to do too much with the defaults and see if they can > get some failures or unexpected behaviors. And then see if 75% > consistently solves it. Not that some folks might need to bump the cap > above 4GB to see an increase if they change the fraction of memory > used for zram. > > For sure this only seems like magic. The efficacy of disk based swap > is 100%. When a page is evicted, 100% of it goes to disk and 0% > remains in memory. For swaponzram, the efficacy depends on the > compression ratio. It's definitely not 0% (unless it's random or > encrypted data) and it's definitely not 100% even if it's all zeros in > the page. But we're going to get at least 50% efficacy. The overall > efficiency of memory utilization is still better. But yeah, in tight > situations it could be a problem. We need to learn more. 75% and 6G > for the cap might be better. But that also has a risk for upgrades, > which is that now on a 6G RAM system, /dev/zram is 4.5G which might > consume 2.3G RAM. So it's going to be a particularly special workload > that really wants to live fully in 4+ GB of memory. If it has to do a > bunch of paging in and out through? It's certainly going to be faster > still than doing that same paging to/from disk based swap. > > And for sure it is better than the noswap case, which means 0% > eviction efficacy. Those anonymous pages can't go anywhere, they're > pinned in RAM. At least with a zram based swap, they take up 1/2 or > less the memory. > > So it's a bit more like magic than not. It's pretty cool. But yeah we > should try to break it. > > > > -- > 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 >
_______________________________________________ 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
