slowdown is a program that makes a process run slower. It is not about
CPU priorioties. It's about reducing I/O speed, a little bit like
traffic shaping, but not really .
Why do I want something to run slower?!
A system backup may thoroughly mess up the buffer cache on a machine,
and prevent other processes from getting "a word in edgewise", due to
prefetch behavior. Slowing down the backup process can help
interactive performance a lot.
For example: slowdown 12345
Where "12345" is the pid of your backup process
Say you are installing a system over a network, and you want to keep
tabs on how it's progressing by running a sniffer like tethereal
against the machine you're sniffing. You don't need to see every
packet possible - you only need a general idea on whether the
process is continuing, or has gotten stuck. Running slowdown
against your sniffer process can sometimes reduce the load
considerably on the machine you're sniffing from.
For example: slowdown 0.01 tethereal host installing.machine.uci.edu
Ever noticed that your linux system gets dog slow while
"updatedb" is running? Apparently some systems are disabling it
by default now, but a better solution might be to let it run, but
control how fast it runs using slowdown.
For example, instead of "updatedb" in /etc/cron.daily/slocate, use
"slowdown 0.0001 updatedb"
Say you want to transfer a file via your home network uplink to
work, but you're using ssh or VNC or something at the same time. It
can really help a lot with interactive performance to put a
slowdown on your file transfer.
This software is owned by The university of California, Irvine,
and is not distributed under
any version of the GPL. GPL is a fine series of licenses, but the owners of the software need it to be distributed under these terms.
Usage is like:
slowdown 0.5 12345
...where "0.5" is the time to pause in seconds, and 12345 is the pid of
a process to manage.
slowdown -v 2.0 /bin/ls
...where "2.0" is the time to pause in seconds, and "/bin/ls" is the
program to manage. slowdown will operate verbosely. A new instance of
/bin/ls will be spawned by slowdown.
The linux version is based on ptrace(). As such, it is somewhat
CPU-dependent. So far, only x86 and x86-64 are supported.
The solaris version is based on /proc. As such, it should be
How does it work?
Slowdown catches a specific set of system calls, which will vary from
platform to platform, but they're all I/O related. Slowdown forces
the subprocess to sleep an arbitrary number of (fractions of) seconds
each time such a system call is executed, slowing down the process
enough to allow other processes to get a word in edgewise.
Neither version knows how to follow fork(), vfork(), or clone().
However, you can achieve almost the same effect by running
strace or whatever against the process tree you want to slow
down, and then run slowdown against the strace.
Two different people who work(ed) for Sun have told me that
ptrace() is a poor design. I have to agree: ptrace makes you
delve into individual registers and their meanings, while /proc is
reasonably well abstracted.
The Solaris can be finicky about what compiler you build with.
You may even end up using a mix of SUNWspro C and gcc.
All data blocks are paused for, not just the large ones
that contribute to the slowdown far more.
Slowdown isn't about CPU-hogging processes. That's more of a job
for something else, like nice, renice, a queuing system like NQS or
loadleveler, my IQS program,
In versions prior to the Apr 9, 2005 release, the Linux ptrace()
version could not attach to a process that slowdown did not fork()
Versions before 2005-05-12 had two known problems:
strcmp wasn't declared properly on suns
The SunOS.c monitor function was missing the verbose parameter
Versions prior to the 2005-06-05 release would leave the
monitoring process wedged if you interrupted (usually control-C)
a slowdown process.
In these older versions, just run "kill -CONT
<pid>", but a signal handler for TERM and INT has since been
added that will kill -CONT for you automatically. Note that kill
-9 may still leave the monitored process wedged, since -9
is not catchable.
Versions prior to the 2005-06-10 release would sometimes
exit prematurely on linux systems, due to ptrace() returning an
error indication (-1), but errno indicating that nothing was
wrong. The 2005-06-10 version checks if errno is 0 when ptrace
returns -1, and if so, continues as if nothing were wrong.
Some versions prior to 2005-06-22, on a linux build, would
mistakenly try to use SYS_pread64 and SYS_pwrite64 syscalls on
systems (EG RHEL3 some or all of the time) that did not define
them. Noticed by Garrick Staples of USC - thanks Garrick.
It might be nice to have the option of saying "only do the
slowdown for blocks that are of size >= 1024", for example.
It would definitely be nice to be able to follow across fork, vfork,
clone and any other related syscalls, down to child processes.
It might be nice to the option of not slowing down for the
first n relevant syscalls, as there are often a lot of irrelevant
syscalls that seem relevant, as a process initializes. For
example, when you're doing a file transfer via rsync over ssh, and
you put a slowdown on the ssh process, you can end up waiting
quite a while for ssh to ask for your authentication data - it'd
be nice to be able to get to the point of entering auth data
quickly, and only slow things down after that.
What'd be even cooler, is if you had a GUI window that would pop
up, and you could drag a slider to control how fast or slow the
There should probably be a sort of fixed point interpretation of the number of seconds to sleep, because
a float cannot really get precise enough.
ionice - doesn't
use a debugger interface; it's a cleaner way when available