Re: Enable EarlyOOM on Fedora KDE - Fedora 33 Self-Contained Change proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday, July 7, 2020 8:54:40 AM MST Przemek Klosowski via devel wrote:
> On 7/6/20 6:49 PM, John M. Harris Jr wrote:
> > Unless you're actively using all of those tabs (I don't know how you would
> > be, but it's certainly possible), swap sounds like the perfect solution.
> > Unless Firefox keeps JS running in there, and it's updating the DOM,
> > these would likely be able to get swapped out.
> > 
> > Firefox will actually unload tabs that you haven't done anything with in a
> > while under specific circumstances, but I don't know what those are. You
> > may notice, for example, that the page "reloads" without network traffic,
> > when going to a tab you haven't had open in a while. I've seen this on my
> > system recently.
> 
> Take a look at the Task Manager. You will see tabs running even though
> you're not touching that: the pages have elements (ads, animations, etc)
> that run even though the tabs are not visible. True, the browser tries
> to pacify them (turns off sound/video, and whatnot) but they still
> run---and if the JS engine has memory leaks their memory footprint
> increases. You can see the culprits---sort them by "Energy Impact" or
> "Memory" by clicking on the column headers.

I don't really use web browsers on "intensive" pages, so I've never noticed 
that sort of issue, but I alluded to that above, JS running or updating the 
DOM. Most of the pages I use, with the exception of those included in Fedora's 
repos (doh), don't require JavaScript in order to function, for example, LWN.

Really, this is starting to sound like it's more of an issue with web 
browsers, and less of a problem with our current configurations, without 
EarlyOOM needlessly killing things.

> >> More swap doesn't necessarily solve this problem: remember that 1GB/min
> >> is a ballpark HD speed so if you have 10GB swap  that your system is
> >> actually trying to use, you will just sit there for 10 minutes.
> > 
> > I don't really understand how that'd be the case. For that to happen,
> > you'd
> > have to load all of those into memory, have them swap out, then try to
> > swap
> > them all back in at the same time.
> 
> That's my point---you don't have control over it. Swap algorithm decides
> which pages are evicted from RAM or brought back---if the browser starts
> allocating memory, my FreeCAD might get pushed out, and if I click on
> GIMP window after not using it for an hour it tries to bring it back in.

You do have control over it, with the swappiness value, for example. 
Currently, pages that haven't been used in a while are the ones that would get 
swapped out first, which I'm sure we can all agree is the most sane option. 
Your GIMP example is accurate, but that'll take a fraction of a second.

> One way to think about it is that disk is tens of thousands times slower
> than RAM. If you need to use it, your system is commensurably slower.
> That's why zram is such a good idea. Swap was always a tradeoff: you
> saved $'s not spent on RAM, and paid with your time sitting idle waiting
> for the computer.

Well, no. It's not "tens of thousands times slower than RAM". If you need to 
use it, you're swapping in a few pages at a time, not the entire contents of 
swap. Swap isn't a replacement for RAM. It's an optimization that doesn't 
waste RAM needlessly.

> With the modern way of computing, where your data is mostly NOT on your
> system---so you don't lose it if your application shuts down---I am
> beginning to think that application crashes aren't such a big deal as
> they used to be. I'd rather crash and restart where I left off than have
> the computer drag me along trying to save my application.

Sorry, what? Why would your data not be on your system? What about "the modern 
way of computing" would move your data from your system to something else? I'd 
rather not see software crash, and risk data loss, or have my system "drag me 
along".

> Having said that, of course lots of applications ARE local and will lose
> data if crashed, so maybe the cgroup-based approach is the definitive
> solution: hard-limit the memory for cloud apps, to protect the local
> apps from resource exhaustion.

How would you differentiate between "cloud apps" and "local apps"? Are you 
defining "cloud apps" as things that run in web browsers, or use a web browser 
engine, or just anything running from a remote system? If the web browser 
approach, I'd support that handling.

-- 
John M. Harris, Jr.

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux