hammer2 - Optimize hammer2 support threads and dispatch

Operating Systems / DragonFlyBSD - Matthew Dillon [apollo.backplane.com] - 28 September 2019 21:10 EDT

- Refactor the XOP groups in order to be able to queue strategy calls, whenever possible, to the same CPU as the issuer. This optimizes several cases and reduces unnecessary IPI traffic between cores. The next best thing to do would be to not queue certain XOPs to an H2 support thread at all, but I would like to keep the threads intact for later clustering work.

The best scaling case for this is when one has a large number of user threads doing I/O. One instance of a single-threaded program on an otherwise idle machine might see a slightly reduction in performance but at the same time we completely avoid unnecessarily spamming all cores in the system on the behalf of a single program, so overhead is also significantly lower.

- This will tend to increase the number of H2 support threads since we need a certain degree of multiplication for domain separation.

- This should significantly increase I/O performance for multi-threaded workloads.

6b039a3d8e hammer2 - Optimize hammer2 support threads and dispatch
sys/vfs/hammer2/hammer2.h | 6 +++---
sys/vfs/hammer2/hammer2_admin.c | 32 ++++++++++++++++++++------------
sys/vfs/hammer2/hammer2_disk.h | 2 +-
sys/vfs/hammer2/hammer2_vfsops.c | 28 ++++++++++++++++------------
4 files changed, 40 insertions(+), 28 deletions(-)

Upstream: gitweb.dragonflybsd.org


  • Share