If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
Fedora 32 Looking At Using EarlyOOM By Default To Better Deal With Low Memory Situations
Everyone seems so bent on one special solution. One solution isn't going to work everywhere, so let's instead identify where different systems, well, differ. Expose a few knobs, and let them be dialed in. Server/default? What we have now is probably pretty close. Desktop? The newest process probably has the least amount of valuable stuff going on. Mobile/embedded? Least recently used. Same thing with the scheduler. Stop trying to make CFS do everything. PDS works great for a few high priority tasks and reducing everything else (gaming), and real-time for desktop and embedded.
Everyone seems so bent on one special solution. One solution isn't going to work everywhere, so let's instead identify where different systems, well, differ. Expose a few knobs, and let them be dialed in. Server/default? What we have now is probably pretty close. Desktop? The newest process probably has the least amount of valuable stuff going on. Mobile/embedded? Least recently used. Same thing with the scheduler. Stop trying to make CFS do everything. PDS works great for a few high priority tasks and reducing everything else (gaming), and real-time for desktop and embedded.
That's weird. Windows and FreeBSD (and probably MacOS X as well) have been demonstrated to just work⢠with a single solution which fits them all. NIH much?
That's weird. Windows and FreeBSD (and probably MacOS X as well) have been demonstrated to just work⢠with a single solution which fits them all. NIH much?
Do you have problems with out of memory problems under FreeBSD?
I am having problems for many years with unresponsive machines when they get without memory and/or swap. As far I can tell, when swap is enabled it will just prolong agony before some application is killed.
Tonight around 5AM I was...
You look smarter when you post just one comment per page.
Everyone seems so bent on one special solution. One solution isn't going to work everywhere, so let's instead identify where different systems, well, differ. Expose a few knobs, and let them be dialed in. Server/default? What we have now is probably pretty close. Desktop? The newest process probably has the least amount of valuable stuff going on. Mobile/embedded? Least recently used. Same thing with the scheduler. Stop trying to make CFS do everything. PDS works great for a few high priority tasks and reducing everything else (gaming), and real-time for desktop and embedded.
I think people are trying to solve the wrong problem here..
The solution is the same one that has always existed. Have enough ram for your workload.
The problem isn't that Linux can't deal with this situation preferably to everyones satisfaction as that situation doesn't exist. You have a subscription over resources available, something has to fail. The *real* problem and the one that needs to be addressed is not how Linux deals with that problem, it's why Linux hangs and gets into a unresponsive state when it is in that situation.
Do you have problems with out of memory problems under FreeBSD?
I am having problems for many years with unresponsive machines when they get without memory and/or swap. As far I can tell, when swap is enabled it will just prolong agony before some application is killed.
Tonight around 5AM I was...
You look smarter when you post just one comment per page.
Well, I believed the testimony of a person earlier in this discussion - don't blame me for that ;-) This still leaves us with Windows which is known to work in this case just fine. And among Linux and FreeBSD, Windows is the only OS which was primarily developed for the desktop.
Well, I believed the testimony of a person earlier in this discussion - don't blame me for that ;-) This still leaves us with Windows which is known to work in this case just fine. And among Linux and FreeBSD, Windows is the only OS which was primarily developed for the desktop.
I think you're justified. Don't take my previous comment too personal, please.
That's weird. Windows and FreeBSD (and probably MacOS X as well) have been demonstrated to just work⢠with a single solution which fits them all. NIH much?
Ah yes, which is why windows server is the dominant high-performance server and embedded OS right? And FreeBSD code is /never/ touched by anyone for any deployment.
Right tool for the right job.
Well, I believed the testimony of a person earlier in this discussion - don't blame me for that ;-) This still leaves us with Windows which is known to work in this case just fine. And among Linux and FreeBSD, Windows is the only OS which was primarily developed for the desktop.
For at least Windows and macOS, they have a more tightly-coupled and desktop-focused userspace, and I believe they have made their respective kernels aware of which pages it can safely swap and not hurt responsiveness of the desktop. But with Linux it's a complete wild-west as to what could be running on top of it, so it can't reliably know what is important and what isn't quite as easily.
Comment