On Mon, Sep 17, 2018 at 10:19 AM, <mcatanzaro@xxxxxxxxx> wrote: > On Mon, Sep 17, 2018 at 9:07 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> > wrote: >> >> I think the issue is that it's it's _possible_ that a out-of-control >> process >> could suddenly eat up a bunch of memory and go to swap right at the wrong >> time. If there's enough space, this is unlikely in practical use. I'm not >> super worried, because realistically that out-of-control processes and >> runaway swap thrashing was going to take your system down or at the very >> least trigger OOM killing *anyway*. > > > Matthew, this happens *all the time* to me and to other developers I work > with when building software. All the time. I fine-tune my ninjaargs to > figure out the highest -j I can use when building without killing my > desktop. We shouldn't have to do this. We're not talking about out of > control processes, we're talking about running make or ninja exactly as > designed: it's expected to spawn a huge number of GCC subprocesses (4, 8, > 32...), each one will want 1-2 GB of RAM... the Fedora desktop should remain > smooth and performant under this load and throttle ninja as needed, not > freeze up. > > If zram or zswap will help such that the desktop doesn't freeze up, then > great, let's try that. [root@f29h ~]# cat /proc/sys/vm/swappiness 60 This is now widely regarded as sabotage, because it's simply too aggressive for the amount of RAM we have these days compared to 4MB of RAM. Upstream is unlikely to change it, they've been beaten over the head for years about it. Try # echo 1 > /proc/sys/vm/swappiness Now do whatever normally blows things up, and report back. I'm kinda curious. If the problem is simply too aggressive swapping, then neither zram nor zswap will make that much of a difference (it will moderate the transition to depending on swap, but once it's pathological, you'll still be screwed if this is really just a workload for which swappiness 60 is flat out bad). -- Chris Murphy _______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
