|
alright let’s do this. without overcommit your app that ran yesterday won’t run today because you have an open browser tab that has too many images that you haven’t looked at in six hours.
|
#
¿
Aug 1, 2020 17:56
|
|
|
|
| # ¿ May 19, 2024 16:07 |
|
|
let’s clarify what it means to run without overcommit. it can be one of several things. 1. every process gets a fixed size memory segment. it does not grow or shrink. 2. every process gets a fixed size memory segment, but libraries are loaded in a shared region. 3. processes can grow their memory allocation. if a process tries to grow and there is not enough available memory, its request is denied and it needs to deal with the consequences. 4. processes can grow. if there is not enough memory, the OS asks other processes to release some memory. if processes don’t release memory, too bad. 5. same but if processes don’t release memory, the os kills them. numbers 1 and 2 require processes to know their maximum memory requirement, and temporally waste a large amount of memory. it is also very restrictive because processes need to avoid temporary ballooning of memory allocations because they will either need to request a larger segment or they will hit the ceiling of their allocation. number 3 is anarchy. an unfortunate combination of processes that happen to hit a memory peak at the same time can exclude each other and deadlock the system. programmers must be able to handle allocation failures everywhere. most code thinks it’s doing it, but rarely are those paths all tested and correct. number 4 is the same as 3. many processes cannot reasonably halt what they are doing and release memory at request time. memory becomes a contended resource with processes repeatedly trying to acquire more to get their work done, and ignoring release requests. the system ends in memory deadlock again when memory high tide hits. number 5 is the out of memory killer. it sucks. and killing processes that have other processes depending on them can be catastrophic and unrecoverable, requiring a userland reboot
|
|
#
¿
Aug 3, 2020 05:47
|
|
|
DuckConference posted:ex-girlfriend wants to get back together don’t DuckConference posted:embedded javascript don’t
|
|
#
¿
Aug 3, 2020 07:53
|
|
|
also, no overcommit in an embedded system where there’s no paging and no user-installed apps is perfectly reasonable.
|
|
#
¿
Aug 3, 2020 07:57
|
|
|
DuckConference posted:(gf stuff) looks like we found the true calling of this thread. I don’t know what it’s like dating in the time of the plague, but I do know that getting back with your ex is a desperation move and it will be depressing from the minute the afterglow of the first boning wears off. DuckConference posted:sadly I can do nothing to prevent or change the javascript, and the system is already way too short on memory to ever turn off overcommit. I’ve been there, with a super-slow storage device that made paging painful. the technical solution is none, it’s hosed and it’s going to be bad if it ever ships. now is the time to cover your rear end. the long term solution is not to work with idiots and to get sign off on the specs of the system before it is made. the short term solution is to blame the people who got you into this. go to your management and tell them that they’ve put you in an impossible situation and they will have to eat this turd that they created. then you can try to put in a heroic effort and rescue it, but you’re setting yourself up for not getting blamed when it’s still terrible.
|
|
#
¿
Aug 3, 2020 18:06
|
|
|
don’t overcommit to doomed relationships
|
|
#
¿
Aug 6, 2020 07:39
|
|
|
|
| # ¿ May 19, 2024 16:07 |
|
|
Kazinsal posted:browsers should be hibernating tabs you haven't used in ages / other tabs by last use time and memory consumption when memory constraints arise ah, okay, so you should wait until the browser hibernates tabs before launching your app. how long is that? what if you just accidentally clicked on the browser window 2 seconds ago? what if it doesn’t do a very good job of releasing memory because of lazy programming? your suggestion takes a function (swap) out of the kernel and distributes it to every app, relying on them to implement it cooperatively and correctly. it also requires them to have enough core functionality always in memory to be able to restore the rest of their state. that means not evicting their program text, unless they want to dynamically load and unload major parts of their code. the complexity ramps up very fast here.
|
|
#
¿
Aug 6, 2020 16:28
|
|