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.
...or...
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.

Supported architectures:

1. The linux version is based on ptrace(). As such, it is somewhat CPU-dependent. So far, only x86 and x86-64 are supported.
2. The solaris version is based on /proc. As such, it should be pretty CPU-independent.

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.

Known bugs:

1. 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.
2. 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.
3. The Solaris can be finicky about what compiler you build with. You may even end up using a mix of SUNWspro C and gcc.
4. All data blocks are paused for, not just the large ones that contribute to the slowdown far more.
5. 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 or IQS2 programs, "verynice", &c.
6. In versions prior to the Apr 9, 2005 release, the Linux ptrace() version could not attach to a process that slowdown did not fork() itself.
7. Versions before 2005-05-12 had two known problems:
   1. strcmp wasn't declared properly on suns
   2. The SunOS.c monitor function was missing the verbose parameter
8. 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.
9. 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.
10. 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.

Future directions:

1. It might be nice to have the option of saying "only do the slowdown for blocks that are of size >= 1024", for example.
2. It would definitely be nice to be able to follow across fork, vfork, clone and any other related syscalls, down to child processes.
3. 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.
4. 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 process runs!
5. 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.

Related work:

• ionice - doesn't use a debugger interface; it's a cleaner way when available
• cgroups - nicer than ionice?

You can e-mail the author with questions or comments: