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