Virtual memory: Difference between revisions

From Helpful
Jump to navigation Jump to search
Line 15: Line 15:




At low level, memory access is "ask for an address, do request, get back result".
At low level, memory access is "give an address, do request for it, get back result".


In olden times, every program could access all memory,
In olden times, every program could access all memory,
themselves and directly in the sense that there is nothing to keep you from doing it.
themselves,
and directly in the sense that there is nothing in the way to keep you from doing it.


Because you all used the same memory space,
Because you all used the same memory space,
memory management was a more cooperative thing.  
memory management was a more... cooperative thing.


But that was hard, and beyond conventions to what bits were operating system and you wouldn't touch,
But that was hard, and beyond conventions to what bits were operating system and you wouldn't touch,
there were no standards to multiple processes running concurrently unless they actively knew about each other.
there were no standards to multiple processes running concurrently, unless they actively knew about each other.


Which was fine because multitasking wasn't a buzzword yet.  
Which was fine because multitasking wasn't a buzzword yet.
We ran one thing at a time, with few exceptions.  
We ran one thing at a time, with few exceptions.






To skip a lot of history, what we now have is a '''virtual memory system''',
To skip a lot of history, what we now have is a '''virtual memory system''',
where running code never deals ''directly'' with physical addresses.
where our running code ''never'' deals ''directly'' with physical addresses.
 
It just means there's something inbetween - mostly there to be a little cleverer for you.


Now, each task gets its own address space.  
Now, each task gets its own address space.  
and ''something'' is doing translation between the addresses that the program sees, and the physical addresses and memory that actually goes to.
and ''something'' is doing translation between the addresses that the program sees, and the physical addresses and memory that actually goes to.


The low level implementation is ''interesting'' (like the fact that hardware is actually assisting this),  
{{comment|The low level implementation is ''interesting'' (like the fact that hardware is actually assisting this - things would be terribly slow if it weren't), but these details are also often irrelevant, in that it's always there, and there is little consequence for you - little to optimize)}}
but also less relevant in that it's always there, and there is little consequence for you - little to optimize.
 
 




No matter the actual numbers the addresses have within each task, they can't clash in physical memory (or rather, ''won't'' overlap until you specifically ask for it and the OS specifically allows it - see [[shared memory]]).
And because there is something managing these assignments of parts of memory to tasks,
they cannot overlap/clash in physical memory {{comment|(...until you specifically ask for it, and the OS specifically allows it - see [[shared memory]])}}.




Revision as of 13:31, 28 February 2024

The lower-level parts of computers

General: Computer power consumption · Computer noises

Memory: Some understanding of memory hardware · CPU cache · Flash memory · Virtual memory · Memory mapped IO and files · RAM disk · Memory limits on 32-bit and 64-bit machines

Related: Network wiring notes - Power over Ethernet · 19" rack sizes

Unsorted: GPU, GPGPU, OpenCL, CUDA notes · Computer booting



✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Intro

Swapping / paging; trashing

Overcommitting RAM with disk

On memory scarcity

"How large should my page/swap space be?"

Linux

Swappiness
✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


oom_kill

oom_kill is linux kernel code that starts killing processes when there is enough memory scarcity that memory allocations cannot happen within reasonable time - as this is good indication that it's gotten to the point that we are trashing.


Killing processes sounds like a poor solution.

But consider that an OS can deal with completely running out of memory in roughly three ways:

  • deny all memory allocations until the scarcity stops.
This isn't very useful because
it will affect every program until scarcity stops
if the cause is one flaky program - and it usually is just one - then the scarcity may not stop
programs that do not actually check every memory allocation will probably crash.
programs that do such checks well may have no option but to stop completely (maybe pause)
So in the best case, random applications will stop doing useful things - probably crash, and in the worst case your system will crash.
  • delay memory allocations until they can be satisfied
This isn't very useful because
this pauses all programs that need memory (they cannot be scheduled until we can give them the memory they ask for) until scarcity stops
again, there is often no reason for this scarcity to stop
so typically means a large-scale system freeze (indistinguishable from a system crash in the practical sense of "it doesn't actually do anything")
  • killing the misbehaving application to end the memory scarcity.
This makes a bunch of assumptions that have to be true -- but it lets the system recover
assumes there is a single misbehaving process (not always true, e.g. two programs allocating most of RAM would be fine individually, and needs an admin to configure them better)
...usually the process with the most allocated memory, though oom_kill logic tries to be smarter than that.
assumes that the system has had enough memory for normal operation up to now, and that there is probably one haywire process (misbehaving or misconfigured, e.g. (pre-)allocates more memory than you have)
this could misfire on badly configured systems (e.g. multiple daemons all configured to use all RAM, or having no swap, leaving nothing to catch incidental variation)


Keep in mind that

  • oom_kill is sort of a worst-case fallback
generally
if you feel the need to rely on the OOM, don't.
if you feel the wish to overcommit, don't
oom_kill is meant to deal with pathological cases of misbehaviour
but even then might pick some random daemon rather than the real offender, because in some cases the real offender is hard to define
note that you can isolate likely offenders via cgroups now (also meaning that swapping happens per cgroup)
and apparently oom_kill is now cgroups-aware
  • oom_kill does not always save you.
It seems that if your system is trashing heavily already, it may not be able to act fast enough.
(and possibly go overboard once things do catch up)
  • You may wish to disable oom_kill when you are developing
...or at least equate an oom_kill in your logs as a fatal bug in the software that caused it.
  • If you don't have oom_kill, you may still be able to get reboot instead, by setting the following sysctls:
vm.panic_on_oom=1

and a nonzero kernel.panic (seconds to show the message before rebooting) 

kernel.panic=10


See also


Page faults

See also

Copy on write

Glossary

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Virtual_memory&oldid=94017"