ptg10805159Section 20.9 Performance 785
grained locking to fine-grained locking. On the system used for these tests, coarse-
grained locking is the same as fine-grained locking for one process, but becomes more
expensive (by about 30%) with multiple processes.
We would like the clock time to decrease from coarse-grained to fine-grained
locking, which it does as soon as we start using multiple processes. However,we
expect the system time to remain higher for fine-grained locking for any number of
processes, because we areissuing morefcntlcalls with fine-grained locking than with
coarse-grained locking. If we total the number offcntlcalls in Figure20.6, we have an
average of 87,858 for coarse-grained locking and 115,520 for fine-grained locking. We
expect this increase of 31% morecalls tofcntlto result in increased system time for
fine-grained locking. Therefore, the decrease in system time for fine-grained locking
with two processes, and the relatively small increase with morethan two processes, is
puzzling.
Thereare two reasons for this behavior.First, recall from Figure20.7 that there is no
significant difference between coarse-grained locking times and fine-grained locking
times when there is no contention for the locks. This shows that the CPU overhead of
the extrafcntlcalls doesn’t affect the performance of the test program. The second
reason is that with coarse-grained locking, we hold locks for longer periods of time,
thus increasing the likelihood that other processes will block on a lock. With fine-
grained locking, the locking is done over shorter intervals, so there is less chance that
processes will block. If we count the number of timesfcntlblocks, we will see that
processes block morefrequently with coarse-grained locking. For example, with four
processes, coarse-grained locking blocks almost five times morefrequently than with
fine-grained locking. The extra work that processes need to do to put themselves to
sleep and wake up moreoften with coarse-grained locking increases the system time,
reducing the difference in system times between the two locking approaches.
The final column in Figure20.8, labeled ‘‘ΔSys,’’ is the percentage increase in the
system CPU time from advisory fine-grained locking to mandatory fine-grained
locking. These percentages show that mandatory locking adds significantly (between
20% and 76%) to the system time as concurrency increases.
Since the user code for all these tests is almost identical (thereare some additional
fcntlcalls for both advisory fine-grained and mandatory fine-grained locking), we
expect the user CPU times to be the same across any row.The first time we ran these tests, we measured the user times for coarse-grained locking to be
almost twice as long as the times for fine-grained locking when multiple processes competed
for the locks. Because the two versions of the database arethe same, except for the number of
calls tofcntl,this made no sense. After investigating, we discovered that because therewas
morecontention with coarse-grained locking, processes werewaiting longer,and the operating
system decided to reduce the CPU clock frequency to save power.With fine-grained locking,
therewas moreactivity, so the system increased the CPU clock frequency.This (artificially)
made the coarse-grained locking tests run moreslowly than the fine-grained tests. After
disabling the frequency scaling feature, we measured the performance of the test without this
bias, and the difference in user times was much smaller.The values in the first row of Figure20.8 aresimilar to those for annrecof 2,000 in
Figure20.7. This corresponds to our expectation.