From: Helge Hafting <helge.hafting@aitel.hist.no>
To: pierre-olivier.gaillard@fr.thalesgroup.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: Can on-demand loading of user-space executables be disabled ?
Date: Tue, 31 Jan 2006 09:43:30 +0100 [thread overview]
Message-ID: <43DF2332.3070705@aitel.hist.no> (raw)
In-Reply-To: <43DDE697.5000007@fr.thalesgroup.com>
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
next prev parent reply other threads:[~2006-01-31 8:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-30 10:12 Can on-demand loading of user-space executables be disabled ? P.O. Gaillard
2006-01-31 8:43 ` Helge Hafting [this message]
2006-01-31 10:28 ` Antonio Vargas
2006-02-07 16:45 ` P.O. Gaillard
-- strict thread matches above, loose matches on Subject: below --
2006-01-30 12:00 linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43DF2332.3070705@aitel.hist.no \
--to=helge.hafting@aitel.hist.no \
--cc=linux-kernel@vger.kernel.org \
--cc=pierre-olivier.gaillard@fr.thalesgroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.