cddl/contrib/dtracetoolkit/Examples/threaded_example.txt

   1 The following is a demonstration of the threaded.d script,
   2
   3
   4 Here we run a test program called "cputhread" that creates 4 busy threads
   5 that run at the same time. Here we run it on a server with only 1 CPU,
   6
   7    # threaded.d
   8
   9    2005 Jul 26 02:56:37,
  10
  11      PID: 8516     CMD: cputhread
  12
  13               value  ------------- Distribution ------------- count
  14                   1 |                                         0
  15                   2 |@@@@@@@                                  17
  16                   3 |@@@@@@@@@@@                              28
  17                   4 |@@@@@@@@@@@                              27
  18                   5 |@@@@@@@@@@@                              28
  19                   6 |                                         0
  20    [...]
  21
  22 In the above output, we can see that cputhread has four busy threads with
  23 thread IDs 2, 3, 4 and 5. We are sampling at 100 Hertz, and have caught
  24 each of these threads on the CPU between 17 and 28 times.
  25
  26 Since the above counts add to 100, this is either a sign of a single CPU
  27 server (which it is), or a sign that a multithreaded application may be
  28 running "serialised" - only 1 thread at a time. Compare the above output
  29 to a multi CPU server,
  30
  31
  32
  33 Here we run the same test program on a server with 4 CPUs,
  34
  35    # threaded.d
  36
  37    2005 Jul 26 02:48:44,
  38
  39      PID: 5218     CMD: cputhread
  40
  41               value  ------------- Distribution ------------- count
  42                   1 |                                         0
  43                   2 |@@@@@@@@@@@                              80
  44                   3 |@@@@@@@@@@                               72
  45                   4 |@@@@@@@@@                                64
  46                   5 |@@@@@@@@@@@                              78
  47                   6 |                                         0
  48    [...]
  49
  50 This time the counts add to equal 294, so this program is definitely
  51 running on multiple CPUs at the same time, otherwise this total would
  52 not be beyond our sample rate of 100. The distribution of threads on CPU
  53 is fairly even, and the above serves as an example of a multithreaded
  54 application performing well.
  55
  56
  57
  58 Now we run a test program called "cpuserial", which also create 4 busy
  59 threads, however due to a coding problem (poor use of mutex locks) they
  60 only run one at a time,
  61
  62    # threaded.d
  63
  64    2005 Jul 26 03:07:21,
  65
  66      PID: 5238     CMD: cpuserial
  67
  68               value  ------------- Distribution ------------- count
  69                   2 |                                         0
  70                   3 |@@@@@@@@@@@@                             30
  71                   4 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@             70
  72                   5 |                                         0
  73    [...]
  74
  75 The above looks like we are back on a single CPU server with 100 samples
  76 in total, however we are still on our 4 CPU server. Only two threads have
  77 run, and the above distribution is a good indication that they have
  78 run serialised.
  79
  80
  81
  82 Now more of a fringe case. This version of cpuserial again creates 4 threads
  83 that are all busy and hungry for the CPU, and again we run it on a 4 CPU
  84 server,
  85
  86    # threaded.d
  87
  88    2005 Jul 26 03:25:45,
  89
  90      PID: 5280     CMD: cpuserial
  91
  92               value  ------------- Distribution ------------- count
  93                   1 |                                         0
  94                   2 |@@@@@@@@@@@@@@@                          42
  95                   3 |@@@@@@@@@@@@@@@@@@                       50
  96                   4 |@@@@@@                                   15
  97                   5 |@                                        2
  98                   6 |                                         0
  99    [...]
 100
 101 So all threads are running, good. And with a total of 109, at some point
 102 more than one thread was running at the same time (otherwise this would
 103 not have exceeded 100, bearing in mind a sample rate of 100 Hertz). However,
 104 what is not so good is that with 4 CPUs we have only scored 109 samples -
 105 since all threads are CPU hungry we'd hope that more often they could
 106 run across the CPUs simultaneously; however this wasn't the case. Again,
 107 this fault was created by poor use of mutex locks.
 108