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
> 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.
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
On 1/31/06, Helge Hafting <[email protected]> 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/
[email protected]
[email protected]
Every day, every year
you have to work
you have to study
you have to scene.
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