> superuser could tag these files to be retained in main memory, even when their need ends, to minimize swapping that would occur when another need arises, and the file now has to be reloaded from relatively slow secondary memory. This function has become obsolete due to swapping optimization.
.... "the Linux kernel ignores the sticky bit on files."
I had a lock feature in a distributed-client cache back in the day. You could lock in some tool file etc that you used frequently, so performance would be stable over some long operation e.g. a build.
I always wondered if people were really any better at choosing, than my cache algorithm. Hard to say. Can't really take statistics, because you can't measure the pattern they didn't use!
Just lock the file into memory using:
```vmtouch -l /path/to/binary```
You could also write a small c program that mmap() and mlock() all the executables and shared objects you need and then stays around in the background.
shrug?
Yeah, it'd only really be useful if one was running some type of web service that called an executable, and there is no source code available to do any fastCGI or whatnot.
Modern kernels are probably smart enough to already handle this for repetitive behavior.
Of course you could always profile things to determine what’s happening and whether any of the suggestions actually improve anything.