On Thu, Jul 9, 2020 at 12:53 PM Brandon Nielsen <nielsenb@xxxxxxxxxxx> wrote: > > On 7/9/20 12:24 PM, Alexey A. wrote: > > I agree. I think that 4GB cap is too small and 4 GB may be used quickly. > > > <Snip> > > Since the values being used seem to have been determined somewhat > heuristically for both EarlyOOM and SwapOnZRAM, I was wondering if there > was any prediction for how the values might change if one, the other, or > both get switched on for Server builds? > > SwapOnZRAM in particular is of interest to me. I have one system with a > workload that's bursty on memory use, and when it starts using the swap > the system becomes unresponsive, even using active SSH sessions is not > guaranteed until the contention clears. The last time it happened I > found myself wondering if SwapOnZRAM would make things more pleasant. It > certainly does on my workstation machines, especially memory limited ones. Yeah we need to learn a little more about these cases. Spikes are very well suited by memory base swap (zram) or cache (zswap), because they can absorb the hit way faster than disk based swap. But those pools can become exhausted. So if the workload is spikey but not long lived, that's good for memory based swap. If it's enduring page out, or the anonymous pages become stale, that's a case where we might need a way to dump those to disk based swap still. Eventually I'd like to see either zram's writeback cache option (to disk, something exposed by sysfs but not by zramctl or zram-generator), or zswap have more clear benefit in these cases. So for those who like to experiment, I've got ideas. Also, we can detect reclaim via cgroups. Reclaim can look like swap thrashing in terms of IO. But it's with file pages, rather than anonymous pages. If reclaim pressure is increasing, it means we don't have enough swap. Or something needs to be killed off. Which is it, is the question. So what we don't want to do is just start adding more swap, because then we just end up back in the situation we're trying to solve. There is a need to choreograph a strategy between having enough of and the right kind of swap, a user space oom killer that responds to pressure, and resource control that ensures the apps we care about get minimum cpu, memory, and IO. It is possible to reincorporate disk based swap, possibly dynamically by creating swapfiles, but use resource control to restrict IO so that we don't get runaway swap thrashing. So even though swap partitions are going away by default in F33, does not necessarily mean we're done with disk based swap. These things are super esoteric and highly technical. But it's really been cool being part of this work happening in Fedora. The Workstation WG has been the central launching point of the motivating factors: the UX here is terrible, we have to do better than this. And then we get the kernel cgroup2, mm, zram, zswap folks building really interesting technologies to have the ability to get information about system state and control it. The systemd folks doing the work to make it possible to bridge that kernel work, making it accessible to the desktop developers - where this resource control isolation work is heavily developed in GNOME and KDE. And then it feeds back quite quickly into Fedora. There's a long list of developers who have done 8 bajillion percent more work than my emails and change proposals on these subjects. -- 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
