MongoDB WiredTiger storage not using two CPU cores

As claimed in WiredTiger storage engine description, it provides an ability of better concurrency due to document-level locking. From this post:

WiredTiger scales on modern, multi-CPU architectures. Using a variety of programming techniques such as hazard pointers, lock-free algorithms, fast latching and message passing, WiredTiger performs more work per CPU core than alternative engines.

For some reason, my use case doesn't seem to benefit from this. I have a database with many concurrent writes (mostly updates), and this kind of load can't seem to overcome the limit of 2000 updates per sec. Here is the mongostat 10 output:

insert query update delete getmore command % dirty % used flushes  vsize    res qr|qw ar|aw netIn netOut conn     time
     3   780   1936    141      42     3|0     0.3    1.0       0 717.0M 289.0M   0|0   1|0  433k     6m  141 17:16:32

Disk throughput is not saturated, iostat -x 10 output:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle

          20.56    0.00   20.31    0.10    0.10   58.93

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
xvda              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
xvdb              0.00     5.80    0.00  102.50     0.00  6188.80    60.38     3.46   33.79   0.46   4.72

Given all of this, I assume that the bottleneck is in CPU usage, which is always stable at 100% all the time for mongod process in the top (from the total of 200%, which means that only one CPU from two is used). 58% idle time from iostat also confirms that.

Are there any methods to determine whether the WiredTiger storage is using document-level locking and two CPU cores simultaneously as it should be? Or could this happen due to any reasons other than CPU capacity limit?