lkml.org 
[lkml]   [2006]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date30 Jan 2006 07:00:11 -0500
From linux@horizon ...
SubjectRe: Can on-demand loading of user-space executables be disabled ?
> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-01-30 13:02    [from the cache]
©2003-2010