On Fri, Jun 5, 2020 at 1:38 PM Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > On Fri, 2020-06-05 at 12:18 -0700, John M. Harris Jr wrote: >I'm > > writing this > > email on a Lenovo ThinkPad X200 Tablet with 6 GiB of RAM, where > > giving half of > > my RAM to zram would kill my system's performance, if not quickly > > cause OOM. > > Either you did not read the page or I misunderstand how zram works. It > will take 3G of your memory and call it a SWAP. With a compression. So > essentially, if the starts will be aligned you will end up with 9G of > memory. Of course, if that is not enough, you can add on top of that > swap on the disk. That's basically correct. But that 3G swap when full is not free, it costs 1.5G RAM. It is true that the efficacy of swap-on-zram is not 100% eviction. It's contingent on the compression ratio. If it's 2:1, the swap-on-zram eviction efficacy is 50%. The memory cost is 1/2 of the savings. So you save 1/2. If the compression is 3:1 (which I often see but safer to promote 2:1), 3G /dev/zram0 with full swap costs 1G RAM, saving 2G. Efficacy is ~67%. It is super easy to get confused about this, part of which is it seems like magicsauce, and thus impossible witchcraft. I spent quite a lot of time wrapping my head around this. And it wasn't hours. It was days. I won't admit how many days. Could there be workloads that get close to 1:1 compression? I don't know. I haven't seen it. A synthetic test filling up anonymous pages from /dev/urandom should do this. As a workload gets closer to zero compression, the setup behaves more like noswap. It's not worse than noswap, but it would be worse than disk based swap. Still, it's way faster, so you don't see the swap thrashing. I think such a contrived test could be worth doing just to understand what happens in practice, not just in theory. And also? In a year? No kernel panics. So this code is rather robust. The manifestations will be in user space. And I've also tested this with and without earlyoom, for many months each. And have run webkitgtk compile while giving Firefox 80 tabs. And it is possible with a zram device set to 100% RAM to get into a kind of nutty CPU/memory based thrashing that doesn't end for a long time - which is no different than the same set up with disk based swap, except it lasts even longer to oom and is IO bound. So far, the worst case is that it doesn't make things better. I haven't yet seen it make things worse. But they probably exist, they're just edge cases. And for those workloads, zswap is likely a better way to spill over onto a disk based swap partition, while still getting the benefits of a memory cache. Another likely bad case, is simply overcommitting the system, by making it do something it flat out has insufficient resources for. We know the kernel lacks use space interactivity guarantees. This problem is part of on-going cgroupsv2 resource control to isolate processes that are essentially runaway, and we'll see more of that work in the near future too, both GNOME and KDE. -- 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
