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?!

  1. 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.
  2. 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.
  3. 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.
  4. 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.

download here

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

    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?

    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 program, "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:

    Hits: 12351
    Timestamp: 2024-03-01 12:05:03 PST

    Back to Dan's tech tidbits

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