[SunHELP] Tht Vmstat output

[Nicholas Dronen]

On Tue, Sep 18, 2001 at 11:17:56AM -0700, darshan pai wrote:
> Hello,
> Can anyone explain to me the system call and context switching fields
> of the faults part of vmstat output

System calls are related to context switches.

A system call is, from the point of view of the caller, simply
a function, such as read(2), write(2), fork(2), and others.
(Note that all of them are in section 2 of the manual.)  What
distinguishes a system call from a conventional function, however,
is that is requires the calling process to switch "modes" to
the kernel.  This is often accomplished using a "trap", which
is caught and handled by the kernel.  The calling process, before
calling the system call, will place the arguments to the system
call/function in certain registers.  It then issues a trap
instruction.  The kernel handles the trap, read the arguments
from registers, does whatever it's supposed to do (for example,
read from or write to a device, which you can't do in user mode),
and returns.  When it returns, the process switches from kernel
mode back to user mode.

This is a simple picture of a system call.  It's also not perfectly
accurate for Solaris on SPARC.  What I know I got from reading
and working with Linux on x86, so take what I say here with the
understanding that, while it's in general true, it's not exactly
how things work with Solaris on SPARC.

So, when a process calls a system call, one thing that has to happen
is that the "state" of the process (which consists of the contents
of all registers -- with the exception of the ones with arguments --
and the program counter, which is the address of the current
instruction) is stored in a data structure associated with the
process.  (I think it's often stored in something called a "u"
area in System V lingo -- might be different in Solaris.)  This
state is restored, without clobbering useful things like system
call return codes and such, when the system call returns.

The above paragraph describes one of the two types of context
switches.  The other type occurs when a process has exhaused
its time slice (that is, it's used as much processor time as
it can before it has to be put back on the run queue so other
processes can run) or the process blocks in kernel mode waiting
for I/O (or otherwise blocks), the state of the process (again,
consisting of the registers and the program counter -- maybe one
or two other things) is saved (to the "u" area or whatever --
it's been a while since I've read about it).  This way, when
it's that process's turn to run on the processor again, it can
resume where it left off.

So, in vmstat output, the sy column indicates the number of times
in the specificed any running process has switched from user mode
to kernel mode in order to perform some task that can only be
accomplished by the kernel.

Now, I don't know whether the cs column *includes* the number of
system calls, the number of system calls * 2 (for each direction:
user->kernel, kernel->user), or neither of these.  You can rest
assured, however, that it at least represents the number of times
a process has been put on the sleep or run queues in the specified
interval.

I hope that helps.

Regards,

Nicholas Dronen