6

I was wondering how embedded systems are able run programs bigger than the size of memory. If I had 1 GB of memory and the program was 1.5 GB, would the program load? Are there systems that only use available memory?

  • 1
    This is why you have swap, so quite literally code can be swapped in and out of memory to make sure only those bits required are in memory. – Burhan Khalid Feb 27 '14 at 5:13
  • As Burhan Said Swap is the Virtual memory, It Will get used by the applications when the physical memory (RAM) Get a target load, If there is 8GB of RAM in your machine we need to assign 16GB of Swap means always Double of RAM, Mostly if Desktop machines have More Capacity of RAM we Don't need to Configure a Swap, If it's a Server Sure Must there want a Swap Space, If you need swap to create you can Create it using commands, But you need free space in Disk. – Babin Lonston Feb 27 '14 at 5:18
  • 1
    ypu do not need twice as much swap as RAM. that's simply a rule of thumb, and is becoming worse as RAM gets cheaper. – strugee Feb 27 '14 at 9:15
  • I would assume that embedded systems wouldn't have any programs that big. – evilsoup Feb 27 '14 at 11:27
  • @Lonston, you should configure RAM so you have enough for your normal workload (or expected peak usage), and add swap to handle any exceptional requirements above that. But that is hard to estimate, and as historically RAM was expensive and disk cheap, rough rules of thumb like 2 times RAM came to be. Some initial SunOS kernels had to have swap at least as large as RAM to be able to use it at all, which served to reinforce this. – vonbrand Feb 27 '14 at 13:17
6

1. Virtual memory
The system will ensure that processes will get the requested amount of memory despite being greater than physical memory. By this way the kernel allocates a virtual memory space of the maximum physical memory size it can handle. E.g. on a 32bit machine, the kernel will allocate a total of 2^32 i.e. 4GB of virtual addresses to every process by default.
2. Overcommitting
There is also something called overcommit in Linux, wherein the kernel does respond to memory allocation requests way larger than the physical memory available. Overcommitting will make the kernel allocate virtual memory without any guarantee of corresponding physical memory allocation.
3. Swap space
As the process requiring that much of memory starts actually using that much of memory, the kernel starts scanning for unused memory pages, as well as memory pages of processes with lower priority or that are currently not running. It swaps out this data to the swap space on the secondary storage device, and frees up those pages for your process. This is called page stealing.

By continually repeating step 3, i.e. swapping pages in and out, the kernel manages to show the process an illusion of the memory it requested, which may be greater than memory physically available. Now as you mentioned an embedded system, we have to consider whether swap is enabled on the system or not. If yes, the above 3 points apply. If no, the above 3 points still apply, but only thing is your process will probably either crash or may get killed off by the OOM(Out-Of-Memory) killer. There is also a possibility that the kernel uses OOM killer to kill off other processes to free up more pages for your processes if it deems fit. However, This will happen only if there is no swap space.

  • 2
    Virtual memory and memory overcommitment are not the same. – jlliagre Feb 27 '14 at 12:49
  • Also consider that whatever is unchanged from the program/library file on disk never goes to swap, it is (re)read from there as needed. – vonbrand Feb 27 '14 at 13:13
  • @jlliagre - I agree, I needed to restructure it a bit, which I did. Thanks. – Stark07 Feb 28 '14 at 1:39
  • 1
    You are still slightly incorrect with your definition of overcommiting. The (unrespected) limit is not the physical memory available but the virtual memory (i.e. physical + swap) available. If there is enough free space in the swap area to back a memory reservation, the OS is not overcommiting. – jlliagre Feb 28 '14 at 2:06
  • 1
    You are defining Overcommitting with this sentence: "Overcommitting is allocating virtual memory without any guarantee of corresponding physical memory allocation." Non overcommiting OSes will safely allocate virtual memory without guarantee of physical memory allocation as long as there is enough free swap. – jlliagre Feb 28 '14 at 7:17
3

Nothing particular will happen, just the same as with any process.

Despite popular belief, a program code and data is not loaded as a whole when the program is started. Only a small subset, essentially its entry point (elf table, main function, initial stack) is loaded, and everything else is loaded on demand, i.e. paged in. This will happen when code or data to be accessed are not in a page currently in physical memory.

Similarly, when there is a pressure on RAM, less used pages are swapped out to disk to free space.

If the size of available RAM plus the size of the swap area happen to be too small for all running programs pages to fit, the behavior is OS dependent:

  • Linux and other OSes which overcommit virtual memory will more or less randomly kill some processes to free space.

  • Non overcommiting OSes like Solaris won't allow new processes to start and will refuse new memory reservation (malloc) from existing processes.

0

No. Most of its not used pages will go to swap. If there is no swap (or not enough), it will be killed, and you get a kernel warning.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.