* Alexander Bokovoy: > This is a good note. If zram breaks kernel API promise to user space > (/proc/meminfo is one such API), how can it be enabled by default. I > also would question enabling zram by default if it does not play along > with cgroups. We do depend on cgroups being properly managed by systemd, > including resource allocation. But that's impossible: The existing interfaces assume that there's no RAM compression (or tiers of swap), so something has to give. As these reported numbers are used for auto-sizing heaps and caches, there have to be heuristics that happen to work for the majority of cases. (Similar to what file systems do if they allocate inodes dynamically, but still have to synthesize a reasonable-looking maximum to satisfy the POSIX statvfs interface constraints.) The alternative would be to come up with entirely new interfaces. The container side of things did that, and from that perspective, anything reading /proc/meminfo is already broken and needs to transition to the new interfaces. But that Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill _______________________________________________ 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
