Lots and lots of system time

[Harald Hanche-Olsen]

This thead has laid dormant for several weeks, so just a reminder:
I asked why system time was well above 50 % while I compile macports software.

["Daniel J. Luke" <dluke at geeklair.net> (2011-10-30 15:03:08 UTC)]

> If you really want to know what is going on, you could probably use some of the provided dtrace scripts (or write one up) to track down what is actually happening on the machine.

I have been trying, but I am not learning a lot from my efforts. Here is my feeble attempt at tracing what is happening in the kernel when I compile some macports packages:

; sudo dtrace -qn 'profile-997 /arg0/ { @[func(arg0)] = count(); }
  profile:::tick-1sec /++x==10/ {exit(0);}
  END { trunc(@,10); }'

  NVDAResman`si570ProgramClk                                       43
  mach_kernel`ml_set_interrupts_enabled                           119
  mach_kernel`vm_map_enter                                        157
  mach_kernel`strncmp                                             157
  mach_kernel`strlen                                              344
  NVDAResman`osPciReadDword                                       527
  mach_kernel`dtrace_probe_arg                                   1295
  mach_kernel`dtrace_unregister                                  3217
  mach_kernel`chud                                               4705
  mach_kernel`machine_idle                                       7213

I have no idea what mach_kernel`chud is or does, but it disappears from the list when the compilation is stopped. (So do the dtrace functions, BTW.) The script runs for ten seconds, so the the first trigger should run 9970 times, or perhaps twice that number (because of the two CPU cores of the machine).

Trying to track system calls from userland is even less instructive. I learn that a lot of processes, or rather a lot of threads, are spending a lot of time in psynch_cvwait. But judging from the name, I don't expect that to burn CPU cycles.

It was suggested that disk encryption/decryption burns a lot of CPU time, but other tasks which do lots of disk I/O don't typicall use much CPU time, so I don't think that is the issue.

It was also suggested that it's just the accounting being way off, and there may be something to that. That sounds reasonable enough. But it does feel like package compilation is quite a lot slower than it used to be, so I do indeed suspect that CPU cycles are being burned to no avail. I guess I should do some timing experiments. Does anyone have timing data for building some typical macports packages, on a machine similar to mine (MacBook Pro, 2.66 GHz Intel Core 2 Duo, 8 GB RAM)?

- Harald