Make ZIL operations on zvols use _by_dnode routines

[ryao]

Description

This continues what was started in
0eef1bd by fully converting zvols to
avoid unnecessary dnode_hold() calls. This saves a small amount of CPU
time and slightly improves latencies onsynchronous operations on zvols.

Motivation and Context

I am working on zvol performance at work. While working on larger changes, I noticed unnecessary overhead that is easy to eliminate. Eliminating it brings some small latency improvements from reduced overhead.

How Has This Been Tested?

It has been tested against prophetstor's internal 0.6.5.9 branch using fio:

fio --name=writeiops --filename=/dev/zvol/e7c61cba0e8e4cec8692570e7c9280bf/test --direct=1 --rw=randwrite --bs=4k --numjobs=4 --iodepth=32 --direct=1 --iodepth_batch=16 --iodepth_batch_complete=16 --runtime=1200 --ramp_time=5 --norandommap --time_based --ioengine=libaio --group_reporting --random_distribution=pareto:0.9

The test hardware is 12x M630-DC SSDs, 256GB of RAM and dual Intel(R) Xeon(R) CPU E5-2630 v4 CPUs (20 cores). I tested on a 500GB zvol. I was careful to wait until the cache was hot enough that we weren't reading metadata before evaluating impact.

The branch is using a variation of #5824 (that predates my first day at my new employer last week), so the numbers are not directly applicable to head, but average latencies dropped by ~15%.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the ZFS on Linux code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted and contain Signed-off-by.
• Change has been approved by a ZFS on Linux member.

[mention-bot]

@ryao, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @ahrens and @tuxoko to be potential reviewers.

[ryao]

I am working on bigger changes, but this should help #4880.

[ryao]

@behlendorf The failure is #5195, which is a pre-existing issue. It is unrelated to the patch here.

Also, preliminary testing at Prophetstor with a SLOG device shows a 30% improvement in IOPS from this patch alone.

Edit: I neglected to notice that I had also backported the changes to use by_dnode for zvol_write and zvol_read. They had made little difference in my initial tests (without a slog), but I kept them in my local branch. The dnode_hold in dmu_write_bio definitely would have had some contention with the dnode_hold in the ZIL path. I do not have access to the machine with SLOG that was used at work to isolate this change from that, but I imagine the actual improvement is somewhat less than 30%. Nevertheless, this is a step in the right direction. I believe that the improvement comes mainly from enabling ZIL batch processing to iterate faster.

[ryao]

@sempervictus If you have a synchronous IO intensive workload, this might give you a small boost. You might want to try testing it.

[sempervictus]

Oh yeah, going into the weekend stack for sure. Thank you sir :-)

[behlendorf]

@ryao definitely progress is the right direction! There was discussion in PR4802 of taking this farther and replacing the dbuf_t with a dnode_t in the zvol_state_t. This would remove the need for the _by_dbuf wrappers, and it might buy you a little more performance since you'll be able to eliminate the DB_DNODE_ENTER/EXIT.

[behlendorf]

@ryao let's do this by switching the dbuf_t to a dnode_t in the zvol_state_t and converting all the existing holds.

[behlendorf]

@ryao if you want these improvements to make 0.7.0 can you address the review feedback. We're trying to wrap up the release.

[ryao]

@behlendorf I like the idea of switching to the _by_dnode routines. This is now refreshed.

[behlendorf]

Thanks, looks good. This ends up being a nice simplification too.

[behlendorf]

@ryao one last rebase to resolve a merge conflict and this should be good to go.

[ryao]

@behlendorf It is rebased.

[behlendorf]

@ryao thanks, I'll get this merged after the buildbot finishes its work.

[sempervictus]

Those test failures dont look too good, crash seems to be coming from:

[ 4304.650875] VERIFY(dn->dn_type != DMU_OT_NONE) failed
[ 4304.655793] PANIC at dbuf.c:2303:dbuf_create()

which seems related to this :)

[behlendorf]

@sempervictus I can see why you thought this might be related since it paniced in dbuf_create(), but it's not. The panic occurred in the zil code for a filesystem and not a zvol, it's more likely this is related to 1b7c1e5 which was recently merged. The link for the log in the previous comment.

[sempervictus]

Yeah... That zil PR should probably be backed out or fixed ASAP - my builders are all OK, and first ztest is usually fine, but zloops are all hanging with no stack trace. Often on fletcher inc test according to log (well, last output is fletcher, next one would be fletcher inc). Something in there is not playing well on Linux in ways more subtle than initial automated testing could detect. It also conflicts in what appear to be key areas with @ryao's zil PR, which as I understand it has been beaten up on Linux pretty heavily. Maybe we switch em out and do the conflict resolution from upstream to zol as opposed to making @ryao change his code to match something that's broken?

[behlendorf]

@sempervictus are you able to reproduce those zloop failures on the current master branch as of commit 88c3012. If so can you determine as of which commit you started seeing them.

[behlendorf]

Why was this added? I don't see why it should be needed here or in the write path.

[ryao]

The previous dmu_read_uio_dbuf() function did it. Upon review, it turns out to be unnecessary. I'll remove it.

[ryao]

@behlendorf The failures seem to have disappeared. Why they appeared when I pushed this initally is something of a mystery, but we are passing now. I have made all of the changes you requested. It should be fine to merge now.

[behlendorf]

Thanks @ryao, I'll get this merged.

It turns out the original failure reported by @sempervictus wasn't introduced by this PR. I've seen it one other time against master. I believe it was either introduced by commit 1b7c1e5 or possibly 38240eb. As soon as we can determine which commit actually introduced it we're going to want to either revert that change or if it's straight forward fix it.

I also resubmitted the two failed test runs for the updated version of this patch since they hit unrelated issues. I just wanted to confirm that before merging.