1

I wrote a program daemon that starts some sort of self-healing procedure when the hard drive controller of a computer crashes. This program already works fine, but I have concerns that the program (about 18KB compiled file size) may not be fully loaded into RAM by the operating system and that - when I'm really unlucky - some program pages have to be loaded from the disk exactly when the program has to come active and disk accesses are no longer possible.

After all, most of the time the program stays in an endless loop checking if everything is okay and 95% of the program code isn't used. So, I think, the Kernel may optimize the RAM usage by removing unused program pages from RAM.

So, my question: does Linux load and keep all program code pages into memory, making it unnecessary to access the hard disk again to run the program code itself, once the program has started?

Technical details: Linux Kernel 2.6.36+, about 1 GB of RAM, Debian 5, no swap space active

I already learned that I can prevent swapping by calling mlockall(MCL_CURRENT | MCL_FUTURE);, but wondering if I really need to update my machines.

Community
  • 1
  • 1
Udo G
  • 12,572
  • 13
  • 56
  • 89

2 Answers2

1

No, the program code pages are memory mapped into the address space of the process, not so differently than any other mmap(), so that if you don't access these pages in a long time, they can eventually be removed from RAM. To avoid it, just use the mlockall() call.

rodrigo
  • 94,151
  • 12
  • 143
  • 190
  • However, the file system has a cache, and pages probably stay there (so are often already in RAM the second time you run a program) – Basile Starynkevitch Oct 10 '13 at 12:49
  • @BasileStarynkevitch: If I understand it correctly, the file system cache and the memory mapped files share the same physical memory pages, so if a mmap'ed page is swapped out it is because it is removed from the FS cache. Or you can see it the other way around, it is equivalent. – rodrigo Oct 10 '13 at 14:45
0

From mlockall manual

mlockall() locks all pages mapped into the address space of the calling process.
This  includes  the pages of the code, data and stack segment, as well as shared
libraries, user space kernel data, shared memory, and memory-mapped files.   All
mapped pages are guaranteed to be resident in RAM when the call returns success‐
fully; the pages are guaranteed to stay in RAM until later unlocked.

So, if locked, pages will be here. However, modifying mounted hard disk partition is always great risk, regardless of any kind of locks.

keltar
  • 17,711
  • 2
  • 37
  • 42
  • I didn't say I modify the partition. – Udo G Oct 10 '13 at 12:14
  • if you only reading from raw device - you have no problems at all even without locking – keltar Oct 10 '13 at 12:42
  • In the question I mention a hard disk controller crash. I can't read/write at all to any drive in that situation (in fact, the program exists solely to remedy exactly that failure). – Udo G Oct 10 '13 at 13:07
  • self-healing w/o disk access then? something new. anyway, do you still have any questions? – keltar Oct 10 '13 at 13:53