1

I know that, in Linux, a page of RAM will not be allocated for a page of virtual address space until a virtual address in the page is referenced. However, I'm using embedded Linux in a device where all the ELF files are already resident in RAM(RAM disk) before loading them(starting a process from each ELF file). So I'm thinking if it's possible to allocate RAM for all the code and data in each ELF file while loading it. If this is possible, I think I'll be able to remove each ELF file from RAM as soon as all its code and data have been paged into RAM, so that more memory space will be freed for use in the future.

  • The "loading" part is all kernel operations, which are the inner workings of the execve() system call. I don't think there's any way to do what you're asking for. It's almost possible to do an execve() from user land (stratigery.com/userlandexec.html) but that also is not what you're asking for. – Bruce Ediger Mar 14 '16 at 3:30
3

You can force all of a process' address space to be paged in with tricks like mlockall(), but it won't help you save memory because no matter what the kernel will hold the backing file open for as long as it's mapped into memory (even if you delete it).

What you are looking for is called eXecute In Place (XIP) and is a feature that lets you execute files directly from memory-mapped storage instead of copying into (separate) RAM first.

XIP is very difficult to support because it places severe requirements on how the executable file has to be laid out in storage (in the filesystem, if applicable). For example, sections of the file that are going to be mapped into memory have to be page-aligned in storage and not mixed in with filesystem metadata. Also, the binary will ideally have been compiled as position-independant code so that the run-time linker doesn't have to modify any part of it after it is mapped. Almost no filesystems support XIP.

Luckily, my understanding is that tmpfs does support XIP. If that's correct then your solution is simply to mount a tmpfs filesystem and move the executable file there before running it.


Update after xiaokaoy commented:

If I just move the executable file into tmpfs, will it automatically be able to execute in place? Why? What makes the file page-aligned in RAM? Will the loader check whether the executable file meets the required conditions to run in the XIP way every time it starts to load an executable file?

tmpfs can support XiP because of the way it stores files in RAM. Files in tmpfs are are stored in memory pages with each file being allocated a whole number of memory pages not shared with other files in the tmpfs. (That's why files in tmpfs always occupy a multiple of 4 KiB — the page size.) Data are stored with the first byte of the file in the first byte of its memory page and so on. So when mmap() (or the kernel ELF loader) is called to map pages from the file, it doesn't need to copy the data to new pages, it can just share the pages that already belong to tmpfs — as long as the mapping is aligned (which it should be with ELF).

  • Thanks, Celada. If I just move the executable file into tmpfs, will it automatically be able to execute in place? Why? What makes the file page-aligned in RAM? Will the loader check whether the executable file meets the required conditions to run in the XIP way every time it starts to load an executable file? I searched Google for information about this many times, but all to no avail. – xiaokaoy May 24 '16 at 8:38
  • See updated answer – Celada May 25 '16 at 19:36
  • I got it. Thanks a lot. How about the data section of the ELF? I guess that, like the text section, no separate RAM pages need to be allocated for it until the value of any global variable is to be modified, right? – xiaokaoy May 26 '16 at 2:15
  • Should be, right – Celada May 26 '16 at 21:08

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.