Can Demand Paging be disabled or circumvented?
 

Is it possible to turn off or circumvent demand paging in Linux? I need to be able to load an entire executable into memory before it executes and not just have one page at a time be loaded. Our application cycle times cannot tolerate page faults.

Thanks.

Try the swapoff command:

swapoff -a

see:

man swapoff

------------------
Steve Stites

Swapoff
 

Wouldn't that only affect a program AFTER it is already loaded in memory? That would prevent it from being swapped back out, but would it fix the problem of demand paging the executable in in the first place?

Turn swap off before the program gets loaded for the first time.

---------------------
Steve Stites

In another universe I would allocate page-fixed storage, fetch my (entire) executable into it (once), then transfer control to it.
Sorry, I don't know how to do that in *nix. Got me interested though ...

That's what I was thinking as well
 

I was thinking the same thing, but don't really know how to do that in Linux either. I have done that on SBCs in the past in assembler though.

check out:

Looks handy.
Got any thoughts on how a program (and any shared objects) can be force loaded in their entirety ???.

Just academic interest in my case ...

Sorry, I don't know anything about using it, but like you my interest was piqued by this post.

I googled a bit and found this, where the guy wrote a C wrapper for his program.

Norm

mlockall
 

We use mlockall, but if you notice, there are two flags used, current and future. It locks the pages in and keeps them from being swapped out AFTER the fact. It won't force the executable to be paged in completely at first. If you look into the source for exec.c, the comments from Linus tell the story. He only loads the header and lets demand paging do the rest.

You've probably thought of this, but how about loading the app to a ramdisk? Would that speed things up enough to make the page faults tolerable?

Norm

RAM disk
 

We tried that Friday, it still didn't eliminate the timing issue, the page faults seem to still be taking too much time even using a RAM disk.

What if you ran an assurance test when the program loaded? If you run each function that you need and access each memory location, then your application can start it's real work. This will increase load time, and may be risky if a part of a function lands in a different page that doesn't get loaded.

(I'm not qualified to help here, I'm just curious.)

We do that now
 

We try to do that now, unfortunately, we cannot guarantee that we take all the branches the programs will take when they run. That seems to be the only current way to ensure all the pages get pulled into RAM and get mlocked in, we also try to make sure that we initialize all the data as well.