Thanks Folks!
-Salil
------------------------------
Original Question:
Are frequently used programs cached in memory somehow?
I've got a little tcl app that calls ping every second. It breaks my heart
to *hear* the disk take a hit every time ping is called. Is there a way to
lock ping into memory, preventing a disk hit everytime it is called?
Things sound really ugly when a dozen users call this app!
I tried creating an MFS, and placing the ping executable in it. But I can
still hear the disk grind everytime ping is called -- which really
surprised me. Setting the sticky-bit doesn't help either. (The Archives
say that the sticky-bit on executables is not honored by DEC-UNIX. Why?)
------------------------------
Responses:
From: alan_at_nabeth.cxo.dec.com
Yes. But...
You have to consider the whole torturous path to how a
program is executed.
You type:
% ping
Your shell either appends ping to each path in its PATH
list or searches for "ping" in its hash table. We'll
take the easy example of using csh. It looks in its
table and find that ping is in /sbin/ping. So, it
verifies the command exists, probably using access(2).
access(2) calls the file system specific namei routine
to translate the name into a device number, inode number
(or more likely a vnode). Namei opens / and searches
for the directory sbin. In the worst case, it would
actually have to open the directory "/" and read all the
directory blocks to find the file "sbin". But in most
systems, the name to inode translations of commonly accessed
places will be cache and even if not, the directory blocks
may be. So it has avoided doing 1 KB I/O (the likely size
of /). Now it opens the directory "sbin" and searchs for
"ping". In the worst case it might have to read 2560 bytes
of data, but again the namei and directory data may be
cached. So it finds that ping exists.
The shell then forks a copy of itself, which may involve
other I/O that is probably cached. The creation of virtual
memory may cause something to page out, or some stale buffer
to flush to get more memory however. Then after some house
keeping the shell execs /sbin/ping. Now, the exec code gets
to go through namei, but having recently been down this path,
all of the data is probably cached. Having a device and inode
number, it reads /sbin/ping into memory. On my V4.0B system
this is 32 KB of program. But, since you're doing this with
some frequence, the program may be sitting in the cache, or
the pages from the recently completed version still unmodified,
though on the free list, so the kernel maps them and goes.
Ping itself may have to do some I/O (translate the hostname
to an Internet address).
Then it exits. The kernel sees that ping has been accessed
so it updates the access time, when it closes the file. Of
course any file ping accessed also has it's access time updated.
The point of the tour is that there is lots of potential I/O
going on to run a program. If you're using a shell that doesn't
keep a table of command names, it needs to use access(2) for
every possible name. If you're running a program that runs
ping, much of this gets done on behalf of the program file
and interpreter.
re: Sticky bit.
When the sticky bit was created what passed for virtual memory
was a segment address added to the relative address of a program
to get its physical address. A program was either in memory
or swapped. There was no paging.
When Berkeley added virtual memory, to that early UNIX system
they arranged for free pages to have a few bits that would
describe the state of a page. If a program was executed
soon after being completed, there was a good chance that
the pages were still on the free list and the kernel only had
to modify the bits to put it back in to use. So, much of the
time, frequently executed program didn't need much work to
page-in. And even if the program wasn't on the free list,
the file system based pages, might be in the buffer cache.
I think this version of the system also allocated page/swap
space for all the virtual memory that might need it and,
if old manual pages are to believed, sometimes copied the
program to the page/swap space. This often had the advantage
of making the program text contiguous and more quickly readable.
In these cases the sticky bit was used to indicate that the
page/swap space should be kept even after the program exited,
which sped up start time.
Improved virtual memory subsystems have removed the need
even for this, though there might be some small advantage
to turning on the sticky bit of a program. Especially for
statically linked programs, such as ping. You might want
to try a benchmark to find out.
From: "Eric Z. Ayers" <eric_at_compgen.com>
I doubt that the disk hit is being caused by an access to re-read the
executable image off of disk, unless your system is severely RAM
starved.
It could be that something is being logged into a system log file every time
your run ping - some kind of routing message like an ICMP
re-direct, or a duplicate packet recieved maybe? Check
/var/adm/messages and /var/adm/syslog.dated/* to see if there is some
error message that is being written when you run ping.
-Eric.
From: alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for
Wayward Inodes.)
If you're going to ping the same addresses everytime, you could
save a couple of disk accesses by finding a public version of
ping. I'd guess that it isn't very complicated, so it may be
worth doing. At the same time, disks are designed to handle
far more constant and regular access than you'll produce by
running ping every now and then. Unless you're in a situation
where power savings is essential and all other disk accesses
have been disabled, the disk will be doing something every now
and then anyway.
One other place you might see an access, is an accounting file
if you have it enabled. The regular sync may so force a write
even if no buffers are dirty.
Received on Wed Apr 30 1997 - 16:24:44 NZST