Improve performance for zpool trim on Linux

[usaleem-ix]

Motivation and Context

On Linux, ZFS uses blkdev_issue_discard in vdev_disk_io_trim to issue trim command which is synchronus. In blkdev_issue_discard, submit_bio_wait is used to after calling __blkdev_issue_discard.

Description

This commit updates vdev_disk_io_trim to use __blkdev_issue_discard, which is asynchronous, and submit bio via vdev_submit_bio.

Unfortunately, there isn't any asynchronus version for blkdev_issue_secure_erase, so performance of secure trim will still suffer.

How Has This Been Tested?

CI test runs and manual runs of zpool trim <pool>

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)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[robn]

@usaleem-ix do you have any info on hand about the performance improvements this change gives? I'm not doubting that there's something there, I just want to understand the before & after a little better before I make any changes in this area. Thanks!

[usaleem-ix]

@robn there was an issue where users with typically large pools were experiencing very slow trim operation. Before this change, we saw that ZFS uses synchronous TRIM KPIs on Linux (blkdev_issue_discard) (waiting for request completion), unlike FreeBSD, where it is properly asynchronous.

The problem with synchronous KPI is that ZFS currently has only 4 TRIM issue taskq threads, that means on Linux it can have only 4 TRIM requests per pool running same time. That may be OK for small non-fragmented pool, but for some cases it becomes a problem. So we introduced this patch to use asynchronous KPI (__blkdev_issue_discard).

Unfortunately, I don't have performance improvement numbers at hand for this.

[robn]

No problem, I appreciate the info! That's about what my guess was too. Cheers!