7

If I time a process using the time command, I get output for 'real', 'user', and 'sys'.

My understanding from this discussion is that 'real' is wall time, whereas 'user' and 'sys' are process time.

Does this imply that 'user' and 'sys' will be unaffected by other processes? In other words, if the computer is under heavy load or light load from other processes, it may take more time on the wall clock ('real') to finish my process. But my process may have only required 5 seconds of running time, even though it was spread out over 20 seconds of real-world time.

Am I guaranteed that I'll be told '5 seconds user time' regardless of whatever else the system is doing?

Community
  • 1
Nathan Long
  • 1,623

2 Answers2

7

No. Process/context switches aren't free.

How much other processes running will slow yours down is very system-dependent, but it consists of things like:

  • Every time a processor switches to a different address space (including process), then the MMU cache must be flushed. And probably the processor L1 caches. And maybe the L2 and L3 caches. This will slow down memory access right after your process is resumed (and this counts against your "user" time).

  • On a SMP (or multi-core) box, if two processes are trying to access the same parts of (physical) RAM, the processors must cooperate. This takes time. It is often done at a architecture level, below even the OS. This will count against your user or sys time, depending on when it hit.

  • Quick kernel locking (that doesn't actually schedule another process) will count against your sys time. This is similar to the point above.

  • on NUMA boxes, you may get moved to a different node. Memory access may now be cross-domain, and thus slower

  • other processes may influence power management decisions. For example, pegging more cores will reduce Intel Turbo Boost speeds, to keep the processor package inside its electrical & thermal specs. Even without turbo boost, the processor may be slowed due to excess heat. It can work the other way too—more load may cause the CPU speed governor to increase the CPU speed.

There are other shared resources on a system; if waiting for them doesn't actually involve your process sleeping, then it'll get counted against your user or sys time.

derobert
  • 109,670
  • Thanks for the in-depth answer! I'm disappointed that this is the case, however. Any suggestions on how, if I have sole control of a system, to have other processes "bug off and be quiet" while I'm benchmarking something? I don't want random spikes in my graph because of some unrelated cron job. Right now I'm running a bunch of times and taking averages, but that's kludgy. – Nathan Long Dec 19 '13 at 15:17
  • @NathanLong Well, the obvious way is to stop cron, and as much else as possible. You could also try sched_setscheduler with SCHED_FIFO and a high priority. That should pretty much stop everything else, at least on a single-core system. But I think this would best be asked as a new question, along with the details. – derobert Dec 19 '13 at 17:18
2

Does this imply that 'user' and 'sys' will be unaffected by other processes?

user time can't really be affected by anything else directly. sys time can, since it may include I/O. If there are a bunch of processes trying to access a device at once, the device itself may become busy, such that when your process is actively scheduled, the system has to wait on the device. It should not amount to much because the wait is mostly passive -- adding to real time -- but if it involves repeated polling, that's active.

goldilocks
  • 87,661
  • 30
  • 204
  • 262