Can on-demand loading of user-space executables be disabled ?

Can on-demand loading of user-space executables be disabled ?

[P.O. Gaillard]

Hello,

As far as I understand what happens when I start a Linux program, the executable 
file is mmaped into memory and the execution of the code itself prompts Linux to 
load the required pages of the program.

I expect that this could cause unwanted delays during program execution when a 
function that has never been used (nor loaded into memory) is called. This delay 
could be bigger than 10ms while the 2.6 kernel is usually quite predictable 
thanks to Ingo Molnar and others' work.

Is Linux really using on-demand loading ?
Is it very different from what I described in the first paragraph ?
Can on-demand loading be disabled ? (This would seem convenient for my 
applications since I generally start a program that is meant to run as 
predictably as possible for months.)

    thanks for your help,


   P.O. Gaillard

Re: Can on-demand loading of user-space executables be disabled ?

[linux]

> As far as I understand what happens when I start a Linux program, the
> executable file is mmaped into memory and the execution of the code
> itself prompts Linux to load the required pages of the program.
> 
> I expect that this could cause unwanted delays during program execution
> when a function that has never been used (nor loaded into memory) is
> called. This delay could be bigger than 10ms while the 2.6 kernel is
> usually quite predictable thanks to Ingo Molnar and others' work.
> 
> Is Linux really using on-demand loading ?

Yes.

> Is it very different from what I described in the first paragraph ?

No, not really (it's not different).  The pages are mapped, and brought
in via page faults.  There is read-ahead code, so if you start hitting
sequential pages, it'll read more than is immediately necessary in the
hope of keeping up.

> Can on-demand loading be disabled ? (This would seem convenient for my 
> applications since I generally start a program that is meant to run as 
> predictably as possible for months.)

Well, the easy way to disable on-demand loading is munmap().
Then the data won't be loaded and you'll get SIGSEGV.

However, I don't think that's what you mean.
If you want to keep code in memory, so it can't suffer a page
fault, either on initial load or by being swapped out to make
room for something else, use mlock() or mlockall().

If you just want to encourage (but not *insist*) code to be in memory,
I think Linux implements madvise(MADV_WILLNEED) sensibly.

Re: Can on-demand loading of user-space executables be disabled ?

[Helge Hafting]

P.O. Gaillard wrote:

> Hello,
>
> As far as I understand what happens when I start a Linux program, the 
> executable file is mmaped into memory and the execution of the code 
> itself prompts Linux to load the required pages of the program.
>
> I expect that this could cause unwanted delays during program 
> execution when a function that has never been used (nor loaded into 
> memory) is called. This delay could be bigger than 10ms while the 2.6 
> kernel is usually quite predictable thanks to Ingo Molnar and others' 
> work.

Delays may indeed happen due to something that isn't yet loaded.  They 
may also
happen because of something being swapped out due to memory pressure.
Note that "turning off swap" by not having any swap-device won't help you.
Linux knows that program code can be reloaded from the executable file,
and may decide to drop little-used functions from memory.  They will then
be demand-loaded if they ever are needed again.

>
> Is Linux really using on-demand loading ?
> Is it very different from what I described in the first paragraph ?

Not very.  Just note that linux doesn't load whole functions, it loads
4kB chunks called pages.

> Can on-demand loading be disabled ? (This would seem convenient for my 
> applications since I generally start a program that is meant to run as 
> predictably as possible for months.) 

Probably possible. It would have to be a special use for this to make 
sense though,
don't consider this just to have a "snappier desktop". Loading whole 
executables
and keeping them loaded wastes lots of memory.  Usual programs have 
startup code
that is only used once - it is normally nice that it gets dropped from 
memory
after a while.  This frees up memory for everything else.  Similiarly, 
it is nice that
the cleanup code used to end the program isn't loaded until needed, that
way it doesn't waste space so the program have more memory available for 
work.

Still, if the very occational and short page-in delay is too much for your
specialized use - use mlock.  If demand loading or swapping merely is slow
due to heavy disk usage, put the executables and swap on a spindle
of its own so these disk accesses won't compete with data accesses.

Helge Hafting

Re: Can on-demand loading of user-space executables be disabled ?

[Antonio Vargas]

On 1/31/06, Helge Hafting <helge.hafting@aitel.hist.no> wrote:
> P.O. Gaillard wrote:
>
> > Hello,
> >
> > As far as I understand what happens when I start a Linux program, the
> > executable file is mmaped into memory and the execution of the code
> > itself prompts Linux to load the required pages of the program.
> >
> > I expect that this could cause unwanted delays during program
> > execution when a function that has never been used (nor loaded into
> > memory) is called. This delay could be bigger than 10ms while the 2.6
> > kernel is usually quite predictable thanks to Ingo Molnar and others'
> > work.
>
> Delays may indeed happen due to something that isn't yet loaded.  They
> may also
> happen because of something being swapped out due to memory pressure.
> Note that "turning off swap" by not having any swap-device won't help you.
> Linux knows that program code can be reloaded from the executable file,
> and may decide to drop little-used functions from memory.  They will then
> be demand-loaded if they ever are needed again.
>
> >
> > Is Linux really using on-demand loading ?
> > Is it very different from what I described in the first paragraph ?
>
> Not very.  Just note that linux doesn't load whole functions, it loads
> 4kB chunks called pages.
>
> > Can on-demand loading be disabled ? (This would seem convenient for my
> > applications since I generally start a program that is meant to run as
> > predictably as possible for months.)
>
> Probably possible. It would have to be a special use for this to make
> sense though,
> don't consider this just to have a "snappier desktop". Loading whole
> executables
> and keeping them loaded wastes lots of memory.  Usual programs have
> startup code
> that is only used once - it is normally nice that it gets dropped from
> memory
> after a while.  This frees up memory for everything else.  Similiarly,
> it is nice that
> the cleanup code used to end the program isn't loaded until needed, that
> way it doesn't waste space so the program have more memory available for
> work.
>
> Still, if the very occational and short page-in delay is too much for your
> specialized use - use mlock.  If demand loading or swapping merely is slow
> due to heavy disk usage, put the executables and swap on a spindle
> of its own so these disk accesses won't compete with data accesses.
>

the easy way to force all executables to be in ram all times is:

1. configure the box with zero swap

2. on boot, untar all your executable and .so files to a tmpfs mount.
this is in effect loading them into ram since you have no swap.

3. set the PATH and .so related vars so that all exe and .so files are
gotten from the tmpfs file.


--
Greetz, Antonio Vargas aka winden of network

http://wind.codepixel.com/
windNOenSPAMntw@gmail.com
thesameasabove@amigascne.org

Every day, every year
you have to work
you have to study
you have to scene.

Re: Can on-demand loading of user-space executables be disabled ?

[P.O. Gaillard]

Thank you everybody. Somebody gave me another solution that applies when you can 
recompile the executable and are willing to change the source code : call 
mlockall to lock the process' memory space in memory.

It might be useful to quote the man page :
        mlockall disables paging for 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 mlockall system call returns success-
        fully and they are guaranteed to  stay  in  RAM  until  the  pages  are
        unlocked again by munlock or munlockall or until the process terminates
        or starts another program with exec.  Child processes  do  not  inherit
        page locks across a fork.

As you see, calling mlockall forces all the executable code to be loaded into 
RAM and stay there. This also protects the program from getting swapped out. And 
you can keep your swap for the other programs.

   thanks again,

    P.O. Gaillard