|
Home > Archive > Unix Programming > July 2005 > Can I put my program in memory (does ram disk exist in Unix?)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Can I put my program in memory (does ram disk exist in Unix?)
|
|
|
| Hi all-
I'm porting a very large progarm that should be broken up into smaller
modules, but, for one reason or another, can't be. So I've got this
massive monolithic app that will be called from Initd on AIX (possibly
Linux or Solaris, which is why I'm keeping it very vanilla C) that
takes a few seconds to load from the disk.
I was thinking that if I had some sort of ram disk-like mechanism then
the load would speed up considerably. I know a ram disk wouldn't
survive a reboot, but I could always write a startup script to make
sure the ram disk was available and then copy the program image to it.
I've tried googling for such a thing but found nothing
definite...FreeBSD has something called mount_mfs but there doesn't
seem to be a Linux/Solaris/AIX equivilent.
Any info would be greatly appreciated,
Tacho
| |
| Eric Sosman 2005-07-15, 6:05 pm |
|
Tacho wrote:
> Hi all-
>
> I'm porting a very large progarm that should be broken up into smaller
> modules, but, for one reason or another, can't be. So I've got this
> massive monolithic app that will be called from Initd on AIX (possibly
Do you mean "inetd?"
> Linux or Solaris, which is why I'm keeping it very vanilla C) that
> takes a few seconds to load from the disk.
>
> I was thinking that if I had some sort of ram disk-like mechanism then
> the load would speed up considerably. I know a ram disk wouldn't
> survive a reboot, but I could always write a startup script to make
> sure the ram disk was available and then copy the program image to it.
>
> I've tried googling for such a thing but found nothing
> definite...FreeBSD has something called mount_mfs but there doesn't
> seem to be a Linux/Solaris/AIX equivilent.
On Solaris, you can copy the executable(s) to /tmp,
or more generally, to any tmpfs file system. That's not
guaranteed to keep the bits in RAM, but it will usually
do so unless the system comes under fairly heavy memory
pressure -- in which case a "good citizen" might choose
to yield the RAM anyhow.
A more drastic measure would be to use a little helper
program that mmap'ed the entire executable and mlock'ed it
into physical RAM, and then just sat around doing nothing
to keep it locked there.
Disclaimer: I work for Sun, but don't speak for Sun.
They have no idea what I'm talking about -- and I may not
either, for that matter ;-)
--
Eric.Sosman@sun.com
| |
| Ulrich Hobelmann 2005-07-15, 6:05 pm |
| Tacho wrote:
> Hi all-
>
> I'm porting a very large progarm that should be broken up into smaller
> modules, but, for one reason or another, can't be. So I've got this
> massive monolithic app that will be called from Initd on AIX (possibly
> Linux or Solaris, which is why I'm keeping it very vanilla C) that
> takes a few seconds to load from the disk.
So what? The program's parts will be loaded as needed by the kernel.
> I was thinking that if I had some sort of ram disk-like mechanism then
> the load would speed up considerably. I know a ram disk wouldn't
> survive a reboot, but I could always write a startup script to make
> sure the ram disk was available and then copy the program image to it.
The kernel caches disk pages as it sees fit. When it doesn't want
to keep a page in memory, it just drops it and later reloads it.
If a part of your program is needed, but not present in memory,
it's loaded automatically. It can't get much more convenient ;)
What's the program's load time, and why do you think preloading
would speed it up? (if the program gets loaded by init anyway,
then how could you PREload it?)
If you need to, you can "cat my-file >/dev/null", which sequences
through the file and probably keeps it in the cache, but usually
the kernel's demand-loading (without any help on your part) should
be fine.
--
XML is a prime example of retarded innovation.
-- Erik Meijer and Peter Drayton, Microsoft Corporation
| |
| Barry Margolin 2005-07-15, 6:05 pm |
| In article <1121455766.689721.191840@z14g2000cwz.googlegroups.com>,
"Tacho" <tachoknight@gmail.com> wrote:
> Hi all-
>
> I'm porting a very large progarm that should be broken up into smaller
> modules, but, for one reason or another, can't be. So I've got this
> massive monolithic app that will be called from Initd on AIX (possibly
> Linux or Solaris, which is why I'm keeping it very vanilla C) that
> takes a few seconds to load from the disk.
>
> I was thinking that if I had some sort of ram disk-like mechanism then
> the load would speed up considerably. I know a ram disk wouldn't
> survive a reboot, but I could always write a startup script to make
> sure the ram disk was available and then copy the program image to it.
>
> I've tried googling for such a thing but found nothing
> definite...FreeBSD has something called mount_mfs but there doesn't
> seem to be a Linux/Solaris/AIX equivilent.
Most flavors of Unix now have virtual memory filesystems. On Solaris
it's called tmpfs. It's usually used for mounting /tmp (hence the name
of the filesystem type). These filesystems aren't forced to real RAM,
they live in virtual memory and make use of the swap partition when
necessary.
With VM systems it typically isn't necessary to do what you're trying.
Starting an application doesn't need to load the entire thing into
memory. The system only loads the portions that need to be executed,
and pages everything else out of the executable file on an as-needed
basis. The time taken to copy from the executable into the ramdisk
would probably be longer than just loading the executable the normal
way. If it needs to be run multiple times, subsequence invocations will
usually find that it's already in memory so they won't need to do much
copying anyway.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Matthias Buelow 2005-07-16, 5:50 pm |
| "Tacho" <tachoknight@gmail.com> writes:
>Any info would be greatly appreciated,
I think the only working solution would be to add more RAM.
mkb.
| |
| Roger Leigh 2005-07-16, 5:50 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
"Tacho" <tachoknight@gmail.com> writes:
> I'm porting a very large progarm that should be broken up into smaller
> modules, but, for one reason or another, can't be. So I've got this
> massive monolithic app that will be called from Initd on AIX (possibly
> Linux or Solaris, which is why I'm keeping it very vanilla C) that
> takes a few seconds to load from the disk.
>
> I was thinking that if I had some sort of ram disk-like mechanism then
> the load would speed up considerably. I know a ram disk wouldn't
> survive a reboot, but I could always write a startup script to make
> sure the ram disk was available and then copy the program image to it.
>
> I've tried googling for such a thing but found nothing
> definite...FreeBSD has something called mount_mfs but there doesn't
> seem to be a Linux/Solaris/AIX equivilent.
On Linux, there are at least three options:
1) /dev/rd0 .. /dev/rdn
Normal RAM discs of fixed size, with an appropriate filesystem on
top.
2) ramfs. RAM-based virtual filesystem.
3) tmpfs. VM-based virtual filesystem.
Of the three, /dev/rd is the least flexible (fixed size), ramfs is the
most fragile (no user limits when I last looked, so locks the system
if you fill it). tmpfs is the most flexible (uses VM, i.e. RAM +
swap), and also has size and inode limits with sensible defaults.
However, the speed increases will be negligible at best. Linux (and
most contemporary UNIX) system use mapped memory and demand paging,
which means the entire program is mapped into memory, but pages are
only faulted in on use. This means a 2 MiB executable might only use
128 KiB of core, because it only needs to load the pages you actually
use. Having a big executable does not imply slow load times, because
it won't all be loaded.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFC2Yw1VcFcaSW/ uEgRAjnJAKC4Hs4o1YwF+raXjEvgjUM9s91vXgCg
2EBX
kg1dextldslkwZhSkId5y9g=
=PBz7
-----END PGP SIGNATURE-----
|
|
|
|
|