Bug #4013


backout 6910752/6968206: needs more work

Added by Robert Mustacchi almost 11 years ago. Updated almost 11 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


It's totally broken. Per Keith's RTI:

This is a straight reversion (as applied via patch -R) of the original
change [0] for 6910752 and 6968206; it contains no new or modified
changes.  Please consider this backout for expedited approval and
immediate application.

The original wad has caused or is suspected to have caused innumerable
other bug reports.  See for example 3855, 3195, 2430, 1069, 1032, and
Joyent's OS-2133 [1] (probably 1344) and OS-2415, probably the same as
several of the others.  There has been discussion of these and similar
bugs for years; see for example [2] and [3] as well as previous attempts
[4] at a backout.  The wad has been backed out by Nexenta and Joyent and
most likely every other illumos vendor who maintains a private
repository.  The wad as written introduces known races, is badly
commented in very bad English, does not clearly define the semantics of
the new locking strategy, and apparently provides no meaningful
improvement in the problem it was intended to solve.  While any one of
these reasons would suffice, I have chosen the universal reason given
for all thoroughly hopeless wads for the past 20+ years: "needs more
work".  If any wad deserves such infamy, this one does.

Since the original change was intended to improve performance by
breaking up m_mutex, I ran a few simple performance tests before the
backout and after.  These tests were run using large thread counts on
very fast CPUs with a very fast 12-SSD ZFS backing store attached to
2308 controllers with IT-mode firmware.  Such circumstances should
maximise the impact of lock contention on delivered performance.  The
results show that performance is actually improved slightly after the
backout.  While the tests are not sufficient in scope or scale to prove
this, they are sufficient to show that while the original wad did indeed
reduce lock contention, it had no positive effect on delivered
performance.  The original changes either attacked the wrong root cause
or had impact only under much different circumstances (e.g., on SPARC,
or with different fabrics or controllers).

Tests were run with sysbench 0.4.12 on SmartOS, in a zone with maximum
I/O shares.  No throttling was observed at any point in the tests.
Results and lockstat data may be found at :

Before backout:

withchina.128k.64.dsync.out, lockstat.out.withchina.128k.64.dsync
withchina.512.64.dsync.out, lockstat.out.withchina.512.64.dsync
withchina.87.8.fsync.out, lockstat.out.withchina.87.8.fsync

After backout:

nochina.128k.64.dsync.out, lockstat.out.nochina.128k.64.dsync
nochina.512.64.dsync.out, lockstat.out.nochina.512.64.dsync
nochina.87.8.fsync.out, lockstat.out.nochina.87.8.fsync

Let's kill this with fire, please.


Also available in: Atom PDF