On Thu, Jul 9, 2020 at 8:52 AM John M. Harris Jr <johnmh@xxxxxxxxxxxxx> 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@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
