]> git.proxmox.com Git - mirror_zfs.git/commit - man/man4/zfs.4
More speculative prefetcher improvements
authorAlexander Motin <mav@FreeBSD.org>
Wed, 25 May 2022 17:12:52 +0000 (13:12 -0400)
committerGitHub <noreply@github.com>
Wed, 25 May 2022 17:12:52 +0000 (10:12 -0700)
commit6aa8c21a2ad29ddd4564cdfd4c99048c891b717a
tree2bd844964cc6b8caef2e0cb76302318aefd089a4
parent1d89b989c15acdc9d70878253d68162c3c5c5836
More speculative prefetcher improvements

- Make prefetch distance adaptive: up to 4MB prefetch doubles for
every, hit same as before, but after that it grows by 1/8 every time
the prefetch read does not complete in time to satisfy the demand.
My tests show that 4MB is sufficient for wide NVMe pool to saturate
single reader thread at 2.5GB/s, while new 64MB maximum allows the
same thread to reach 1.5GB/s on wide HDD pool.  Further distance
increase may increase speed even more, but less dramatic and with
higher latency.

 - Allow early reuse of inactive prefetch streams: streams that never
saw hits can be reused immediately if there is a demand, while others
can be reused after 1s of inactivity, starting with the oldest.  After
2s of inactivity streams are deleted to free resources same as before.
This allows by several times increase strided read performance on HDD
pool in presence of simultaneous random reads, previously filling the
zfetch_max_streams limit for seconds and so blocking most of prefetch.

 - Always issue intermediate indirect block reads with SYNC priority.
Each of those reads if delayed for longer may delay up to 1024 other
block prefetches, that may be not good for wide pools.

Reviewed-by: Allan Jude <allan@klarasystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #13452
include/sys/dbuf.h
include/sys/dmu_zfetch.h
man/man4/zfs.4
module/zfs/dbuf.c
module/zfs/dmu_zfetch.c