2008-11-20 23:01:55 +03:00
|
|
|
/*
|
|
|
|
|
* CDDL HEADER START
|
|
|
|
|
*
|
|
|
|
|
* The contents of this file are subject to the terms of the
|
|
|
|
|
* Common Development and Distribution License (the "License").
|
|
|
|
|
* You may not use this file except in compliance with the License.
|
|
|
|
|
*
|
|
|
|
|
* You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
|
2022-07-12 00:16:13 +03:00
|
|
|
* or https://opensource.org/licenses/CDDL-1.0.
|
2008-11-20 23:01:55 +03:00
|
|
|
* See the License for the specific language governing permissions
|
|
|
|
|
* and limitations under the License.
|
|
|
|
|
*
|
|
|
|
|
* When distributing Covered Code, include this CDDL HEADER in each
|
|
|
|
|
* file and include the License file at usr/src/OPENSOLARIS.LICENSE.
|
|
|
|
|
* If applicable, add the following below this CDDL HEADER, with the
|
|
|
|
|
* fields enclosed by brackets "[]" replaced with your own identifying
|
|
|
|
|
* information: Portions Copyright [yyyy] [name of copyright owner]
|
|
|
|
|
*
|
|
|
|
|
* CDDL HEADER END
|
|
|
|
|
*/
|
|
|
|
|
/*
|
2010-05-29 00:45:14 +04:00
|
|
|
* Copyright 2009 Sun Microsystems, Inc. All rights reserved.
|
2008-11-20 23:01:55 +03:00
|
|
|
* Use is subject to license terms.
|
|
|
|
|
*/
|
|
|
|
|
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 07:01:20 +04:00
|
|
|
/*
|
2019-07-08 23:18:50 +03:00
|
|
|
* Copyright (c) 2013, 2017 by Delphix. All rights reserved.
|
Illumos #4045 write throttle & i/o scheduler performance work
4045 zfs write throttle & i/o scheduler performance work
1. The ZFS i/o scheduler (vdev_queue.c) now divides i/os into 5 classes: sync
read, sync write, async read, async write, and scrub/resilver. The scheduler
issues a number of concurrent i/os from each class to the device. Once a class
has been selected, an i/o is selected from this class using either an elevator
algorithem (async, scrub classes) or FIFO (sync classes). The number of
concurrent async write i/os is tuned dynamically based on i/o load, to achieve
good sync i/o latency when there is not a high load of writes, and good write
throughput when there is. See the block comment in vdev_queue.c (reproduced
below) for more details.
2. The write throttle (dsl_pool_tempreserve_space() and
txg_constrain_throughput()) is rewritten to produce much more consistent delays
when under constant load. The new write throttle is based on the amount of
dirty data, rather than guesses about future performance of the system. When
there is a lot of dirty data, each transaction (e.g. write() syscall) will be
delayed by the same small amount. This eliminates the "brick wall of wait"
that the old write throttle could hit, causing all transactions to wait several
seconds until the next txg opens. One of the keys to the new write throttle is
decrementing the amount of dirty data as i/o completes, rather than at the end
of spa_sync(). Note that the write throttle is only applied once the i/o
scheduler is issuing the maximum number of outstanding async writes. See the
block comments in dsl_pool.c and above dmu_tx_delay() (reproduced below) for
more details.
This diff has several other effects, including:
* the commonly-tuned global variable zfs_vdev_max_pending has been removed;
use per-class zfs_vdev_*_max_active values or zfs_vdev_max_active instead.
* the size of each txg (meaning the amount of dirty data written, and thus the
time it takes to write out) is now controlled differently. There is no longer
an explicit time goal; the primary determinant is amount of dirty data.
Systems that are under light or medium load will now often see that a txg is
always syncing, but the impact to performance (e.g. read latency) is minimal.
Tune zfs_dirty_data_max and zfs_dirty_data_sync to control this.
* zio_taskq_batch_pct = 75 -- Only use 75% of all CPUs for compression,
checksum, etc. This improves latency by not allowing these CPU-intensive tasks
to consume all CPU (on machines with at least 4 CPU's; the percentage is
rounded up).
--matt
APPENDIX: problems with the current i/o scheduler
The current ZFS i/o scheduler (vdev_queue.c) is deadline based. The problem
with this is that if there are always i/os pending, then certain classes of
i/os can see very long delays.
For example, if there are always synchronous reads outstanding, then no async
writes will be serviced until they become "past due". One symptom of this
situation is that each pass of the txg sync takes at least several seconds
(typically 3 seconds).
If many i/os become "past due" (their deadline is in the past), then we must
service all of these overdue i/os before any new i/os. This happens when we
enqueue a batch of async writes for the txg sync, with deadlines 2.5 seconds in
the future. If we can't complete all the i/os in 2.5 seconds (e.g. because
there were always reads pending), then these i/os will become past due. Now we
must service all the "async" writes (which could be hundreds of megabytes)
before we service any reads, introducing considerable latency to synchronous
i/os (reads or ZIL writes).
Notes on porting to ZFS on Linux:
- zio_t gained new members io_physdone and io_phys_children. Because
object caches in the Linux port call the constructor only once at
allocation time, objects may contain residual data when retrieved
from the cache. Therefore zio_create() was updated to zero out the two
new fields.
- vdev_mirror_pending() relied on the depth of the per-vdev pending queue
(vq->vq_pending_tree) to select the least-busy leaf vdev to read from.
This tree has been replaced by vq->vq_active_tree which is now used
for the same purpose.
- vdev_queue_init() used the value of zfs_vdev_max_pending to determine
the number of vdev I/O buffers to pre-allocate. That global no longer
exists, so we instead use the sum of the *_max_active values for each of
the five I/O classes described above.
- The Illumos implementation of dmu_tx_delay() delays a transaction by
sleeping in condition variable embedded in the thread
(curthread->t_delay_cv). We do not have an equivalent CV to use in
Linux, so this change replaced the delay logic with a wrapper called
zfs_sleep_until(). This wrapper could be adopted upstream and in other
downstream ports to abstract away operating system-specific delay logic.
- These tunables are added as module parameters, and descriptions added
to the zfs-module-parameters.5 man page.
spa_asize_inflation
zfs_deadman_synctime_ms
zfs_vdev_max_active
zfs_vdev_async_write_active_min_dirty_percent
zfs_vdev_async_write_active_max_dirty_percent
zfs_vdev_async_read_max_active
zfs_vdev_async_read_min_active
zfs_vdev_async_write_max_active
zfs_vdev_async_write_min_active
zfs_vdev_scrub_max_active
zfs_vdev_scrub_min_active
zfs_vdev_sync_read_max_active
zfs_vdev_sync_read_min_active
zfs_vdev_sync_write_max_active
zfs_vdev_sync_write_min_active
zfs_dirty_data_max_percent
zfs_delay_min_dirty_percent
zfs_dirty_data_max_max_percent
zfs_dirty_data_max
zfs_dirty_data_max_max
zfs_dirty_data_sync
zfs_delay_scale
The latter four have type unsigned long, whereas they are uint64_t in
Illumos. This accommodates Linux's module_param() supported types, but
means they may overflow on 32-bit architectures.
The values zfs_dirty_data_max and zfs_dirty_data_max_max are the most
likely to overflow on 32-bit systems, since they express physical RAM
sizes in bytes. In fact, Illumos initializes zfs_dirty_data_max_max to
2^32 which does overflow. To resolve that, this port instead initializes
it in arc_init() to 25% of physical RAM, and adds the tunable
zfs_dirty_data_max_max_percent to override that percentage. While this
solution doesn't completely avoid the overflow issue, it should be a
reasonable default for most systems, and the minority of affected
systems can work around the issue by overriding the defaults.
- Fixed reversed logic in comment above zfs_delay_scale declaration.
- Clarified comments in vdev_queue.c regarding when per-queue minimums take
effect.
- Replaced dmu_tx_write_limit in the dmu_tx kstat file
with dmu_tx_dirty_delay and dmu_tx_dirty_over_max. The first counts
how many times a transaction has been delayed because the pool dirty
data has exceeded zfs_delay_min_dirty_percent. The latter counts how
many times the pool dirty data has exceeded zfs_dirty_data_max (which
we expect to never happen).
- The original patch would have regressed the bug fixed in
zfsonlinux/zfs@c418410, which prevented users from setting the
zfs_vdev_aggregation_limit tuning larger than SPA_MAXBLOCKSIZE.
A similar fix is added to vdev_queue_aggregate().
- In vdev_queue_io_to_issue(), dynamically allocate 'zio_t search' on the
heap instead of the stack. In Linux we can't afford such large
structures on the stack.
Reviewed by: George Wilson <george.wilson@delphix.com>
Reviewed by: Adam Leventhal <ahl@delphix.com>
Reviewed by: Christopher Siden <christopher.siden@delphix.com>
Reviewed by: Ned Bass <bass6@llnl.gov>
Reviewed by: Brendan Gregg <brendan.gregg@joyent.com>
Approved by: Robert Mustacchi <rm@joyent.com>
References:
http://www.illumos.org/issues/4045
illumos/illumos-gate@69962b5647e4a8b9b14998733b765925381b727e
Ported-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1913
2013-08-29 07:01:20 +04:00
|
|
|
*/
|
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
#include <sys/zfs_context.h>
|
2023-03-02 02:27:40 +03:00
|
|
|
#include <sys/arc_impl.h>
|
2008-11-20 23:01:55 +03:00
|
|
|
#include <sys/dnode.h>
|
|
|
|
|
#include <sys/dmu_objset.h>
|
|
|
|
|
#include <sys/dmu_zfetch.h>
|
|
|
|
|
#include <sys/dmu.h>
|
|
|
|
|
#include <sys/dbuf.h>
|
2010-05-29 00:45:14 +04:00
|
|
|
#include <sys/kstat.h>
|
2021-06-17 03:19:34 +03:00
|
|
|
#include <sys/wmsum.h>
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
|
/*
|
2015-12-27 00:10:31 +03:00
|
|
|
* This tunable disables predictive prefetch. Note that it leaves "prescient"
|
|
|
|
|
* prefetch (e.g. prefetch for zfs send) intact. Unlike predictive prefetch,
|
|
|
|
|
* prescient prefetch never issues i/os that end up not being needed,
|
|
|
|
|
* so it can't hurt performance.
|
2008-11-20 23:01:55 +03:00
|
|
|
*/
|
|
|
|
|
|
2022-01-15 02:37:55 +03:00
|
|
|
static int zfs_prefetch_disable = B_FALSE;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
|
/* max # of streams per zfetch */
|
2022-01-15 02:37:55 +03:00
|
|
|
static unsigned int zfetch_max_streams = 8;
|
2008-11-20 23:01:55 +03:00
|
|
|
/* min time before stream reclaim */
|
2022-05-25 20:12:52 +03:00
|
|
|
static unsigned int zfetch_min_sec_reap = 1;
|
|
|
|
|
/* max time before stream delete */
|
|
|
|
|
static unsigned int zfetch_max_sec_reap = 2;
|
2023-07-21 21:51:47 +03:00
|
|
|
#ifdef _ILP32
|
|
|
|
|
/* min bytes to prefetch per stream (default 2MB) */
|
|
|
|
|
static unsigned int zfetch_min_distance = 2 * 1024 * 1024;
|
|
|
|
|
/* max bytes to prefetch per stream (default 8MB) */
|
|
|
|
|
unsigned int zfetch_max_distance = 8 * 1024 * 1024;
|
|
|
|
|
#else
|
2022-05-25 20:12:52 +03:00
|
|
|
/* min bytes to prefetch per stream (default 4MB) */
|
|
|
|
|
static unsigned int zfetch_min_distance = 4 * 1024 * 1024;
|
|
|
|
|
/* max bytes to prefetch per stream (default 64MB) */
|
|
|
|
|
unsigned int zfetch_max_distance = 64 * 1024 * 1024;
|
2023-07-21 21:51:47 +03:00
|
|
|
#endif
|
2016-08-30 00:36:39 +03:00
|
|
|
/* max bytes to prefetch indirects for per stream (default 64MB) */
|
|
|
|
|
unsigned int zfetch_max_idistance = 64 * 1024 * 1024;
|
2024-04-09 01:13:27 +03:00
|
|
|
/* max request reorder distance within a stream (default 16MB) */
|
|
|
|
|
unsigned int zfetch_max_reorder = 16 * 1024 * 1024;
|
|
|
|
|
/* Max log2 fraction of holes in a stream */
|
|
|
|
|
unsigned int zfetch_hole_shift = 2;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
typedef struct zfetch_stats {
|
|
|
|
|
kstat_named_t zfetchstat_hits;
|
2024-04-09 01:13:27 +03:00
|
|
|
kstat_named_t zfetchstat_future;
|
|
|
|
|
kstat_named_t zfetchstat_stride;
|
|
|
|
|
kstat_named_t zfetchstat_past;
|
2010-05-29 00:45:14 +04:00
|
|
|
kstat_named_t zfetchstat_misses;
|
2015-12-27 00:10:31 +03:00
|
|
|
kstat_named_t zfetchstat_max_streams;
|
2020-09-28 03:08:38 +03:00
|
|
|
kstat_named_t zfetchstat_io_issued;
|
2023-03-02 02:27:40 +03:00
|
|
|
kstat_named_t zfetchstat_io_active;
|
2010-05-29 00:45:14 +04:00
|
|
|
} zfetch_stats_t;
|
|
|
|
|
|
|
|
|
|
static zfetch_stats_t zfetch_stats = {
|
|
|
|
|
{ "hits", KSTAT_DATA_UINT64 },
|
2024-04-09 01:13:27 +03:00
|
|
|
{ "future", KSTAT_DATA_UINT64 },
|
|
|
|
|
{ "stride", KSTAT_DATA_UINT64 },
|
|
|
|
|
{ "past", KSTAT_DATA_UINT64 },
|
2010-05-29 00:45:14 +04:00
|
|
|
{ "misses", KSTAT_DATA_UINT64 },
|
2015-12-27 00:10:31 +03:00
|
|
|
{ "max_streams", KSTAT_DATA_UINT64 },
|
2023-03-02 02:27:40 +03:00
|
|
|
{ "io_issued", KSTAT_DATA_UINT64 },
|
|
|
|
|
{ "io_active", KSTAT_DATA_UINT64 },
|
2010-05-29 00:45:14 +04:00
|
|
|
};
|
|
|
|
|
|
2021-06-17 03:19:34 +03:00
|
|
|
struct {
|
|
|
|
|
wmsum_t zfetchstat_hits;
|
2024-04-09 01:13:27 +03:00
|
|
|
wmsum_t zfetchstat_future;
|
|
|
|
|
wmsum_t zfetchstat_stride;
|
|
|
|
|
wmsum_t zfetchstat_past;
|
2021-06-17 03:19:34 +03:00
|
|
|
wmsum_t zfetchstat_misses;
|
|
|
|
|
wmsum_t zfetchstat_max_streams;
|
|
|
|
|
wmsum_t zfetchstat_io_issued;
|
2023-03-02 02:27:40 +03:00
|
|
|
aggsum_t zfetchstat_io_active;
|
2021-06-17 03:19:34 +03:00
|
|
|
} zfetch_sums;
|
|
|
|
|
|
|
|
|
|
#define ZFETCHSTAT_BUMP(stat) \
|
|
|
|
|
wmsum_add(&zfetch_sums.stat, 1)
|
2020-09-28 03:08:38 +03:00
|
|
|
#define ZFETCHSTAT_ADD(stat, val) \
|
2021-06-17 03:19:34 +03:00
|
|
|
wmsum_add(&zfetch_sums.stat, val)
|
2020-09-28 03:08:38 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2022-01-15 02:37:55 +03:00
|
|
|
static kstat_t *zfetch_ksp;
|
2010-05-29 00:45:14 +04:00
|
|
|
|
2021-06-17 03:19:34 +03:00
|
|
|
static int
|
|
|
|
|
zfetch_kstats_update(kstat_t *ksp, int rw)
|
|
|
|
|
{
|
|
|
|
|
zfetch_stats_t *zs = ksp->ks_data;
|
|
|
|
|
|
|
|
|
|
if (rw == KSTAT_WRITE)
|
|
|
|
|
return (EACCES);
|
|
|
|
|
zs->zfetchstat_hits.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_hits);
|
2024-04-09 01:13:27 +03:00
|
|
|
zs->zfetchstat_future.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_future);
|
|
|
|
|
zs->zfetchstat_stride.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_stride);
|
|
|
|
|
zs->zfetchstat_past.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_past);
|
2021-06-17 03:19:34 +03:00
|
|
|
zs->zfetchstat_misses.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_misses);
|
|
|
|
|
zs->zfetchstat_max_streams.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_max_streams);
|
|
|
|
|
zs->zfetchstat_io_issued.value.ui64 =
|
|
|
|
|
wmsum_value(&zfetch_sums.zfetchstat_io_issued);
|
2023-03-02 02:27:40 +03:00
|
|
|
zs->zfetchstat_io_active.value.ui64 =
|
|
|
|
|
aggsum_value(&zfetch_sums.zfetchstat_io_active);
|
2021-06-17 03:19:34 +03:00
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
void
|
|
|
|
|
zfetch_init(void)
|
|
|
|
|
{
|
2021-06-17 03:19:34 +03:00
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_hits, 0);
|
2024-04-09 01:13:27 +03:00
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_future, 0);
|
|
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_stride, 0);
|
|
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_past, 0);
|
2021-06-17 03:19:34 +03:00
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_misses, 0);
|
|
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_max_streams, 0);
|
|
|
|
|
wmsum_init(&zfetch_sums.zfetchstat_io_issued, 0);
|
2023-03-02 02:27:40 +03:00
|
|
|
aggsum_init(&zfetch_sums.zfetchstat_io_active, 0);
|
2021-06-17 03:19:34 +03:00
|
|
|
|
2010-05-29 00:45:14 +04:00
|
|
|
zfetch_ksp = kstat_create("zfs", 0, "zfetchstats", "misc",
|
|
|
|
|
KSTAT_TYPE_NAMED, sizeof (zfetch_stats) / sizeof (kstat_named_t),
|
|
|
|
|
KSTAT_FLAG_VIRTUAL);
|
|
|
|
|
|
|
|
|
|
if (zfetch_ksp != NULL) {
|
|
|
|
|
zfetch_ksp->ks_data = &zfetch_stats;
|
2021-06-17 03:19:34 +03:00
|
|
|
zfetch_ksp->ks_update = zfetch_kstats_update;
|
2010-05-29 00:45:14 +04:00
|
|
|
kstat_install(zfetch_ksp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
|
|
|
|
zfetch_fini(void)
|
|
|
|
|
{
|
|
|
|
|
if (zfetch_ksp != NULL) {
|
|
|
|
|
kstat_delete(zfetch_ksp);
|
|
|
|
|
zfetch_ksp = NULL;
|
|
|
|
|
}
|
2021-06-17 03:19:34 +03:00
|
|
|
|
|
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_hits);
|
2024-04-09 01:13:27 +03:00
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_future);
|
|
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_stride);
|
|
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_past);
|
2021-06-17 03:19:34 +03:00
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_misses);
|
|
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_max_streams);
|
|
|
|
|
wmsum_fini(&zfetch_sums.zfetchstat_io_issued);
|
2023-03-02 02:27:40 +03:00
|
|
|
ASSERT0(aggsum_value(&zfetch_sums.zfetchstat_io_active));
|
|
|
|
|
aggsum_fini(&zfetch_sums.zfetchstat_io_active);
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This takes a pointer to a zfetch structure and a dnode. It performs the
|
|
|
|
|
* necessary setup for the zfetch structure, grokking data from the
|
|
|
|
|
* associated dnode.
|
|
|
|
|
*/
|
|
|
|
|
void
|
|
|
|
|
dmu_zfetch_init(zfetch_t *zf, dnode_t *dno)
|
|
|
|
|
{
|
2015-12-27 00:10:31 +03:00
|
|
|
if (zf == NULL)
|
2008-11-20 23:01:55 +03:00
|
|
|
return;
|
|
|
|
|
zf->zf_dnode = dno;
|
2020-09-28 03:08:38 +03:00
|
|
|
zf->zf_numstreams = 0;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
|
list_create(&zf->zf_stream, sizeof (zstream_t),
|
2015-12-27 00:10:31 +03:00
|
|
|
offsetof(zstream_t, zs_node));
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_init(&zf->zf_lock, NULL, MUTEX_DEFAULT, NULL);
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 03:08:38 +03:00
|
|
|
static void
|
|
|
|
|
dmu_zfetch_stream_fini(zstream_t *zs)
|
|
|
|
|
{
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
ASSERT(!list_link_active(&zs->zs_node));
|
2021-07-01 18:22:16 +03:00
|
|
|
zfs_refcount_destroy(&zs->zs_callers);
|
|
|
|
|
zfs_refcount_destroy(&zs->zs_refs);
|
2020-09-28 03:08:38 +03:00
|
|
|
kmem_free(zs, sizeof (*zs));
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-27 00:10:31 +03:00
|
|
|
static void
|
|
|
|
|
dmu_zfetch_stream_remove(zfetch_t *zf, zstream_t *zs)
|
2008-11-20 23:01:55 +03:00
|
|
|
{
|
2019-07-25 21:57:58 +03:00
|
|
|
ASSERT(MUTEX_HELD(&zf->zf_lock));
|
2015-12-27 00:10:31 +03:00
|
|
|
list_remove(&zf->zf_stream, zs);
|
2020-09-28 03:08:38 +03:00
|
|
|
zf->zf_numstreams--;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
membar_producer();
|
|
|
|
|
if (zfs_refcount_remove(&zs->zs_refs, NULL) == 0)
|
|
|
|
|
dmu_zfetch_stream_fini(zs);
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2015-12-27 00:10:31 +03:00
|
|
|
* Clean-up state associated with a zfetch structure (e.g. destroy the
|
|
|
|
|
* streams). This doesn't free the zfetch_t itself, that's left to the caller.
|
2008-11-20 23:01:55 +03:00
|
|
|
*/
|
|
|
|
|
void
|
2015-12-27 00:10:31 +03:00
|
|
|
dmu_zfetch_fini(zfetch_t *zf)
|
2008-11-20 23:01:55 +03:00
|
|
|
{
|
2015-12-27 00:10:31 +03:00
|
|
|
zstream_t *zs;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_enter(&zf->zf_lock);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
while ((zs = list_head(&zf->zf_stream)) != NULL)
|
|
|
|
|
dmu_zfetch_stream_remove(zf, zs);
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_exit(&zf->zf_lock);
|
2008-11-20 23:01:55 +03:00
|
|
|
list_destroy(&zf->zf_stream);
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_destroy(&zf->zf_lock);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
|
|
|
|
zf->zf_dnode = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
2022-05-25 20:12:52 +03:00
|
|
|
* If there aren't too many active streams already, create one more.
|
|
|
|
|
* In process delete/reuse all streams without hits for zfetch_max_sec_reap.
|
|
|
|
|
* If needed, reuse oldest stream without hits for zfetch_min_sec_reap or ever.
|
2015-12-27 00:10:31 +03:00
|
|
|
* The "blkid" argument is the next block that we expect this stream to access.
|
2008-11-20 23:01:55 +03:00
|
|
|
*/
|
2015-12-27 00:10:31 +03:00
|
|
|
static void
|
|
|
|
|
dmu_zfetch_stream_create(zfetch_t *zf, uint64_t blkid)
|
2008-11-20 23:01:55 +03:00
|
|
|
{
|
2022-05-25 20:12:52 +03:00
|
|
|
zstream_t *zs, *zs_next, *zs_old = NULL;
|
2024-04-09 01:13:27 +03:00
|
|
|
uint_t now = gethrestime_sec(), t;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2019-07-25 21:57:58 +03:00
|
|
|
ASSERT(MUTEX_HELD(&zf->zf_lock));
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2015-12-27 00:10:31 +03:00
|
|
|
/*
|
2022-05-25 20:12:52 +03:00
|
|
|
* Delete too old streams, reusing the first found one.
|
2015-12-27 00:10:31 +03:00
|
|
|
*/
|
2024-04-09 01:13:27 +03:00
|
|
|
t = now - zfetch_max_sec_reap;
|
2022-05-25 20:12:52 +03:00
|
|
|
for (zs = list_head(&zf->zf_stream); zs != NULL; zs = zs_next) {
|
2015-12-27 00:10:31 +03:00
|
|
|
zs_next = list_next(&zf->zf_stream, zs);
|
2020-09-28 03:08:38 +03:00
|
|
|
/*
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
* Skip if still active. 1 -- zf_stream reference.
|
2020-09-28 03:08:38 +03:00
|
|
|
*/
|
2024-04-09 01:13:27 +03:00
|
|
|
if ((int)(zs->zs_atime - t) >= 0)
|
2020-09-28 03:08:38 +03:00
|
|
|
continue;
|
2024-04-09 01:13:27 +03:00
|
|
|
if (zfs_refcount_count(&zs->zs_refs) != 1)
|
2022-05-25 20:12:52 +03:00
|
|
|
continue;
|
|
|
|
|
if (zs_old)
|
2015-12-27 00:10:31 +03:00
|
|
|
dmu_zfetch_stream_remove(zf, zs);
|
2022-05-25 20:12:52 +03:00
|
|
|
else
|
|
|
|
|
zs_old = zs;
|
|
|
|
|
}
|
|
|
|
|
if (zs_old) {
|
|
|
|
|
zs = zs_old;
|
2024-04-09 01:13:27 +03:00
|
|
|
list_remove(&zf->zf_stream, zs);
|
2022-05-25 20:12:52 +03:00
|
|
|
goto reuse;
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
2015-12-27 00:10:31 +03:00
|
|
|
/*
|
|
|
|
|
* The maximum number of streams is normally zfetch_max_streams,
|
|
|
|
|
* but for small files we lower it such that it's at least possible
|
|
|
|
|
* for all the streams to be non-overlapping.
|
|
|
|
|
*/
|
2017-11-04 23:25:13 +03:00
|
|
|
uint32_t max_streams = MAX(1, MIN(zfetch_max_streams,
|
2024-04-09 01:13:27 +03:00
|
|
|
(zf->zf_dnode->dn_maxblkid << zf->zf_dnode->dn_datablkshift) /
|
2015-12-27 00:10:31 +03:00
|
|
|
zfetch_max_distance));
|
2020-09-28 03:08:38 +03:00
|
|
|
if (zf->zf_numstreams >= max_streams) {
|
2024-04-09 01:13:27 +03:00
|
|
|
t = now - zfetch_min_sec_reap;
|
2022-05-25 20:12:52 +03:00
|
|
|
for (zs = list_head(&zf->zf_stream); zs != NULL;
|
|
|
|
|
zs = list_next(&zf->zf_stream, zs)) {
|
2024-04-09 01:13:27 +03:00
|
|
|
if ((int)(zs->zs_atime - t) >= 0)
|
2022-05-25 20:12:52 +03:00
|
|
|
continue;
|
2024-04-09 01:13:27 +03:00
|
|
|
if (zfs_refcount_count(&zs->zs_refs) != 1)
|
2022-05-25 20:12:52 +03:00
|
|
|
continue;
|
2024-04-09 01:13:27 +03:00
|
|
|
if (zs_old == NULL ||
|
|
|
|
|
(int)(zs_old->zs_atime - zs->zs_atime) >= 0)
|
2022-05-25 20:12:52 +03:00
|
|
|
zs_old = zs;
|
|
|
|
|
}
|
|
|
|
|
if (zs_old) {
|
|
|
|
|
zs = zs_old;
|
2024-04-09 01:13:27 +03:00
|
|
|
list_remove(&zf->zf_stream, zs);
|
2022-05-25 20:12:52 +03:00
|
|
|
goto reuse;
|
|
|
|
|
}
|
2015-12-27 00:10:31 +03:00
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_max_streams);
|
|
|
|
|
return;
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
2022-05-25 20:12:52 +03:00
|
|
|
zs = kmem_zalloc(sizeof (*zs), KM_SLEEP);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
zfs_refcount_create(&zs->zs_callers);
|
|
|
|
|
zfs_refcount_create(&zs->zs_refs);
|
|
|
|
|
/* One reference for zf_stream. */
|
|
|
|
|
zfs_refcount_add(&zs->zs_refs, NULL);
|
2020-09-28 03:08:38 +03:00
|
|
|
zf->zf_numstreams++;
|
2022-05-25 20:12:52 +03:00
|
|
|
|
|
|
|
|
reuse:
|
2024-04-09 01:13:27 +03:00
|
|
|
list_insert_head(&zf->zf_stream, zs);
|
2022-05-25 20:12:52 +03:00
|
|
|
zs->zs_blkid = blkid;
|
2024-04-09 01:13:27 +03:00
|
|
|
/* Allow immediate stream reuse until first hit. */
|
|
|
|
|
zs->zs_atime = now - zfetch_min_sec_reap;
|
|
|
|
|
memset(zs->zs_ranges, 0, sizeof (zs->zs_ranges));
|
2022-05-25 20:12:52 +03:00
|
|
|
zs->zs_pf_dist = 0;
|
2024-04-09 01:13:27 +03:00
|
|
|
zs->zs_ipf_dist = 0;
|
2022-05-25 20:12:52 +03:00
|
|
|
zs->zs_pf_start = blkid;
|
|
|
|
|
zs->zs_pf_end = blkid;
|
|
|
|
|
zs->zs_ipf_start = blkid;
|
|
|
|
|
zs->zs_ipf_end = blkid;
|
|
|
|
|
zs->zs_missed = B_FALSE;
|
|
|
|
|
zs->zs_more = B_FALSE;
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
2020-09-28 03:08:38 +03:00
|
|
|
static void
|
2022-05-25 20:12:52 +03:00
|
|
|
dmu_zfetch_done(void *arg, uint64_t level, uint64_t blkid, boolean_t io_issued)
|
2020-09-28 03:08:38 +03:00
|
|
|
{
|
|
|
|
|
zstream_t *zs = arg;
|
|
|
|
|
|
2022-05-25 20:12:52 +03:00
|
|
|
if (io_issued && level == 0 && blkid < zs->zs_blkid)
|
|
|
|
|
zs->zs_more = B_TRUE;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
if (zfs_refcount_remove(&zs->zs_refs, NULL) == 0)
|
2020-09-28 03:08:38 +03:00
|
|
|
dmu_zfetch_stream_fini(zs);
|
2023-03-02 02:27:40 +03:00
|
|
|
aggsum_add(&zfetch_sums.zfetchstat_io_active, -1);
|
2020-09-28 03:08:38 +03:00
|
|
|
}
|
|
|
|
|
|
2024-04-09 01:13:27 +03:00
|
|
|
/*
|
|
|
|
|
* Process stream hit access for nblks blocks starting at zs_blkid. Return
|
|
|
|
|
* number of blocks to proceed for after aggregation with future ranges.
|
|
|
|
|
*/
|
|
|
|
|
static uint64_t
|
|
|
|
|
dmu_zfetch_hit(zstream_t *zs, uint64_t nblks)
|
|
|
|
|
{
|
|
|
|
|
uint_t i, j;
|
|
|
|
|
|
|
|
|
|
/* Optimize sequential accesses (no future ranges). */
|
|
|
|
|
if (zs->zs_ranges[0].start == 0)
|
|
|
|
|
goto done;
|
|
|
|
|
|
|
|
|
|
/* Look for intersections with further ranges. */
|
|
|
|
|
for (i = 0; i < ZFETCH_RANGES; i++) {
|
|
|
|
|
zsrange_t *r = &zs->zs_ranges[i];
|
|
|
|
|
if (r->start == 0 || r->start > nblks)
|
|
|
|
|
break;
|
|
|
|
|
if (r->end >= nblks) {
|
|
|
|
|
nblks = r->end;
|
|
|
|
|
i++;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Delete all found intersecting ranges, updates remaining. */
|
|
|
|
|
for (j = 0; i < ZFETCH_RANGES; i++, j++) {
|
|
|
|
|
if (zs->zs_ranges[i].start == 0)
|
|
|
|
|
break;
|
|
|
|
|
ASSERT3U(zs->zs_ranges[i].start, >, nblks);
|
|
|
|
|
ASSERT3U(zs->zs_ranges[i].end, >, nblks);
|
|
|
|
|
zs->zs_ranges[j].start = zs->zs_ranges[i].start - nblks;
|
|
|
|
|
zs->zs_ranges[j].end = zs->zs_ranges[i].end - nblks;
|
|
|
|
|
}
|
|
|
|
|
if (j < ZFETCH_RANGES) {
|
|
|
|
|
zs->zs_ranges[j].start = 0;
|
|
|
|
|
zs->zs_ranges[j].end = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
done:
|
|
|
|
|
zs->zs_blkid += nblks;
|
|
|
|
|
return (nblks);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Process future stream access for nblks blocks starting at blkid. Return
|
|
|
|
|
* number of blocks to proceed for if future ranges reach fill threshold.
|
|
|
|
|
*/
|
|
|
|
|
static uint64_t
|
|
|
|
|
dmu_zfetch_future(zstream_t *zs, uint64_t blkid, uint64_t nblks)
|
|
|
|
|
{
|
|
|
|
|
ASSERT3U(blkid, >, zs->zs_blkid);
|
|
|
|
|
blkid -= zs->zs_blkid;
|
|
|
|
|
ASSERT3U(blkid + nblks, <=, UINT16_MAX);
|
|
|
|
|
|
|
|
|
|
/* Search for first and last intersection or insert point. */
|
|
|
|
|
uint_t f = ZFETCH_RANGES, l = 0, i;
|
|
|
|
|
for (i = 0; i < ZFETCH_RANGES; i++) {
|
|
|
|
|
zsrange_t *r = &zs->zs_ranges[i];
|
|
|
|
|
if (r->start == 0 || r->start > blkid + nblks)
|
|
|
|
|
break;
|
|
|
|
|
if (r->end < blkid)
|
|
|
|
|
continue;
|
|
|
|
|
if (f > i)
|
|
|
|
|
f = i;
|
|
|
|
|
if (l < i)
|
|
|
|
|
l = i;
|
|
|
|
|
}
|
|
|
|
|
if (f <= l) {
|
|
|
|
|
/* Got some intersecting range, expand it if needed. */
|
|
|
|
|
if (zs->zs_ranges[f].start > blkid)
|
|
|
|
|
zs->zs_ranges[f].start = blkid;
|
|
|
|
|
zs->zs_ranges[f].end = MAX(zs->zs_ranges[l].end, blkid + nblks);
|
|
|
|
|
if (f < l) {
|
|
|
|
|
/* Got more than one intersection, remove others. */
|
|
|
|
|
for (f++, l++; l < ZFETCH_RANGES; f++, l++) {
|
|
|
|
|
zs->zs_ranges[f].start = zs->zs_ranges[l].start;
|
|
|
|
|
zs->zs_ranges[f].end = zs->zs_ranges[l].end;
|
|
|
|
|
}
|
|
|
|
|
zs->zs_ranges[ZFETCH_RANGES - 1].start = 0;
|
|
|
|
|
zs->zs_ranges[ZFETCH_RANGES - 1].end = 0;
|
|
|
|
|
}
|
|
|
|
|
} else if (i < ZFETCH_RANGES) {
|
|
|
|
|
/* Got no intersecting ranges, insert new one. */
|
|
|
|
|
for (l = ZFETCH_RANGES - 1; l > i; l--) {
|
|
|
|
|
zs->zs_ranges[l].start = zs->zs_ranges[l - 1].start;
|
|
|
|
|
zs->zs_ranges[l].end = zs->zs_ranges[l - 1].end;
|
|
|
|
|
}
|
|
|
|
|
zs->zs_ranges[i].start = blkid;
|
|
|
|
|
zs->zs_ranges[i].end = blkid + nblks;
|
|
|
|
|
} else {
|
|
|
|
|
/* No space left to insert. Drop the range. */
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check if with the new access addition we reached fill threshold. */
|
|
|
|
|
if (zfetch_hole_shift >= 16)
|
|
|
|
|
return (0);
|
|
|
|
|
uint_t hole = 0;
|
|
|
|
|
for (i = f = l = 0; i < ZFETCH_RANGES; i++) {
|
|
|
|
|
zsrange_t *r = &zs->zs_ranges[i];
|
|
|
|
|
if (r->start == 0)
|
|
|
|
|
break;
|
|
|
|
|
hole += r->start - f;
|
|
|
|
|
f = r->end;
|
|
|
|
|
if (hole <= r->end >> zfetch_hole_shift)
|
|
|
|
|
l = r->end;
|
|
|
|
|
}
|
|
|
|
|
if (l > 0)
|
|
|
|
|
return (dmu_zfetch_hit(zs, l));
|
|
|
|
|
|
|
|
|
|
return (0);
|
|
|
|
|
}
|
|
|
|
|
|
2008-11-20 23:01:55 +03:00
|
|
|
/*
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
* This is the predictive prefetch entry point. dmu_zfetch_prepare()
|
|
|
|
|
* associates dnode access specified with blkid and nblks arguments with
|
|
|
|
|
* prefetch stream, predicts further accesses based on that stats and returns
|
|
|
|
|
* the stream pointer on success. That pointer must later be passed to
|
|
|
|
|
* dmu_zfetch_run() to initiate the speculative prefetch for the stream and
|
|
|
|
|
* release it. dmu_zfetch() is a wrapper for simple cases when window between
|
|
|
|
|
* prediction and prefetch initiation is not needed.
|
2016-08-30 00:36:39 +03:00
|
|
|
* fetch_data argument specifies whether actual data blocks should be fetched:
|
|
|
|
|
* FALSE -- prefetch only indirect blocks for predicted data blocks;
|
|
|
|
|
* TRUE -- prefetch predicted data blocks plus following indirect blocks.
|
2008-11-20 23:01:55 +03:00
|
|
|
*/
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
zstream_t *
|
|
|
|
|
dmu_zfetch_prepare(zfetch_t *zf, uint64_t blkid, uint64_t nblks,
|
|
|
|
|
boolean_t fetch_data, boolean_t have_lock)
|
2008-11-20 23:01:55 +03:00
|
|
|
{
|
2015-12-27 00:10:31 +03:00
|
|
|
zstream_t *zs;
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
spa_t *spa = zf->zf_dnode->dn_objset->os_spa;
|
2023-10-24 21:00:07 +03:00
|
|
|
zfs_prefetch_type_t os_prefetch = zf->zf_dnode->dn_objset->os_prefetch;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2023-10-24 21:00:07 +03:00
|
|
|
if (zfs_prefetch_disable || os_prefetch == ZFS_PREFETCH_NONE)
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
return (NULL);
|
2023-10-24 21:00:07 +03:00
|
|
|
|
|
|
|
|
if (os_prefetch == ZFS_PREFETCH_METADATA)
|
|
|
|
|
fetch_data = B_FALSE;
|
|
|
|
|
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
/*
|
|
|
|
|
* If we haven't yet loaded the indirect vdevs' mappings, we
|
|
|
|
|
* can only read from blocks that we carefully ensure are on
|
|
|
|
|
* concrete vdevs (or previously-loaded indirect vdevs). So we
|
|
|
|
|
* can't allow the predictive prefetcher to attempt reads of other
|
2019-09-03 03:56:41 +03:00
|
|
|
* blocks (e.g. of the MOS's dnode object).
|
OpenZFS 7614, 9064 - zfs device evacuation/removal
OpenZFS 7614 - zfs device evacuation/removal
OpenZFS 9064 - remove_mirror should wait for device removal to complete
This project allows top-level vdevs to be removed from the storage pool
with "zpool remove", reducing the total amount of storage in the pool.
This operation copies all allocated regions of the device to be removed
onto other devices, recording the mapping from old to new location.
After the removal is complete, read and free operations to the removed
(now "indirect") vdev must be remapped and performed at the new location
on disk. The indirect mapping table is kept in memory whenever the pool
is loaded, so there is minimal performance overhead when doing operations
on the indirect vdev.
The size of the in-memory mapping table will be reduced when its entries
become "obsolete" because they are no longer used by any block pointers
in the pool. An entry becomes obsolete when all the blocks that use
it are freed. An entry can also become obsolete when all the snapshots
that reference it are deleted, and the block pointers that reference it
have been "remapped" in all filesystems/zvols (and clones). Whenever an
indirect block is written, all the block pointers in it will be "remapped"
to their new (concrete) locations if possible. This process can be
accelerated by using the "zfs remap" command to proactively rewrite all
indirect blocks that reference indirect (removed) vdevs.
Note that when a device is removed, we do not verify the checksum of
the data that is copied. This makes the process much faster, but if it
were used on redundant vdevs (i.e. mirror or raidz vdevs), it would be
possible to copy the wrong data, when we have the correct data on e.g.
the other side of the mirror.
At the moment, only mirrors and simple top-level vdevs can be removed
and no removal is allowed if any of the top-level vdevs are raidz.
Porting Notes:
* Avoid zero-sized kmem_alloc() in vdev_compact_children().
The device evacuation code adds a dependency that
vdev_compact_children() be able to properly empty the vdev_child
array by setting it to NULL and zeroing vdev_children. Under Linux,
kmem_alloc() and related functions return a sentinel pointer rather
than NULL for zero-sized allocations.
* Remove comment regarding "mpt" driver where zfs_remove_max_segment
is initialized to SPA_MAXBLOCKSIZE.
Change zfs_condense_indirect_commit_entry_delay_ticks to
zfs_condense_indirect_commit_entry_delay_ms for consistency with
most other tunables in which delays are specified in ms.
* ZTS changes:
Use set_tunable rather than mdb
Use zpool sync as appropriate
Use sync_pool instead of sync
Kill jobs during test_removal_with_operation to allow unmount/export
Don't add non-disk names such as "mirror" or "raidz" to $DISKS
Use $TEST_BASE_DIR instead of /tmp
Increase HZ from 100 to 1000 which is more common on Linux
removal_multiple_indirection.ksh
Reduce iterations in order to not time out on the code
coverage builders.
removal_resume_export:
Functionally, the test case is correct but there exists a race
where the kernel thread hasn't been fully started yet and is
not visible. Wait for up to 1 second for the removal thread
to be started before giving up on it. Also, increase the
amount of data copied in order that the removal not finish
before the export has a chance to fail.
* MMP compatibility, the concept of concrete versus non-concrete devices
has slightly changed the semantics of vdev_writeable(). Update
mmp_random_leaf_impl() accordingly.
* Updated dbuf_remap() to handle the org.zfsonlinux:large_dnode pool
feature which is not supported by OpenZFS.
* Added support for new vdev removal tracepoints.
* Test cases removal_with_zdb and removal_condense_export have been
intentionally disabled. When run manually they pass as intended,
but when running in the automated test environment they produce
unreliable results on the latest Fedora release.
They may work better once the upstream pool import refectoring is
merged into ZoL at which point they will be re-enabled.
Authored by: Matthew Ahrens <mahrens@delphix.com>
Reviewed-by: Alex Reece <alex@delphix.com>
Reviewed-by: George Wilson <george.wilson@delphix.com>
Reviewed-by: John Kennedy <john.kennedy@delphix.com>
Reviewed-by: Prakash Surya <prakash.surya@delphix.com>
Reviewed by: Richard Laager <rlaager@wiktel.com>
Reviewed by: Tim Chase <tim@chase2k.com>
Reviewed by: Brian Behlendorf <behlendorf1@llnl.gov>
Approved by: Garrett D'Amore <garrett@damore.org>
Ported-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Tim Chase <tim@chase2k.com>
OpenZFS-issue: https://www.illumos.org/issues/7614
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/f539f1eb
Closes #6900
2016-09-22 19:30:13 +03:00
|
|
|
*/
|
|
|
|
|
if (!spa_indirect_vdevs_loaded(spa))
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
return (NULL);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2015-12-27 00:10:31 +03:00
|
|
|
/*
|
|
|
|
|
* As a fast path for small (single-block) files, ignore access
|
|
|
|
|
* to the first block.
|
|
|
|
|
*/
|
2020-09-28 03:08:38 +03:00
|
|
|
if (!have_lock && blkid == 0)
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
return (NULL);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2019-07-08 23:18:50 +03:00
|
|
|
if (!have_lock)
|
|
|
|
|
rw_enter(&zf->zf_dnode->dn_struct_rwlock, RW_READER);
|
2020-09-28 03:08:38 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A fast path for small files for which no prefetch will
|
|
|
|
|
* happen.
|
|
|
|
|
*/
|
2022-05-25 20:12:52 +03:00
|
|
|
uint64_t maxblkid = zf->zf_dnode->dn_maxblkid;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
if (maxblkid < 2) {
|
2020-09-28 03:08:38 +03:00
|
|
|
if (!have_lock)
|
|
|
|
|
rw_exit(&zf->zf_dnode->dn_struct_rwlock);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
return (NULL);
|
2020-09-28 03:08:38 +03:00
|
|
|
}
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_enter(&zf->zf_lock);
|
2008-11-20 23:01:55 +03:00
|
|
|
|
OpenZFS 8835 - Speculative prefetch in ZFS not working for misaligned reads
In case of misaligned I/O sequential requests are not detected as such
due to overlaps in logical block sequence:
dmu_zfetch(fffff80198dd0ae0, 27347, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27355, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27363, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27371, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27379, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27387, 9, 1)
This patch makes single block overlap to be counted as a stream hit,
improving performance up to several times.
Authored by: Alexander Motin <mav@FreeBSD.org>
Approved by: Gordon Ross <gwr@nexenta.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Allan Jude <allanjude@freebsd.org>
Reviewed by: Gvozden Neskovic <neskovic@gmail.com>
Reviewed by: George Melikov <mail@gmelikov.ru>
Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
OpenZFS-issue: https://www.illumos.org/issues/8835
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/aab6dd482a
Closes #7062
2017-11-20 20:56:01 +03:00
|
|
|
/*
|
2024-04-09 01:13:27 +03:00
|
|
|
* Find perfect prefetch stream. Depending on whether the accesses
|
OpenZFS 8835 - Speculative prefetch in ZFS not working for misaligned reads
In case of misaligned I/O sequential requests are not detected as such
due to overlaps in logical block sequence:
dmu_zfetch(fffff80198dd0ae0, 27347, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27355, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27363, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27371, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27379, 9, 1)
dmu_zfetch(fffff80198dd0ae0, 27387, 9, 1)
This patch makes single block overlap to be counted as a stream hit,
improving performance up to several times.
Authored by: Alexander Motin <mav@FreeBSD.org>
Approved by: Gordon Ross <gwr@nexenta.com>
Reviewed by: Matthew Ahrens <mahrens@delphix.com>
Reviewed by: Allan Jude <allanjude@freebsd.org>
Reviewed by: Gvozden Neskovic <neskovic@gmail.com>
Reviewed by: George Melikov <mail@gmelikov.ru>
Ported-by: Brian Behlendorf <behlendorf1@llnl.gov>
OpenZFS-issue: https://www.illumos.org/issues/8835
OpenZFS-commit: https://github.com/openzfs/openzfs/commit/aab6dd482a
Closes #7062
2017-11-20 20:56:01 +03:00
|
|
|
* are block-aligned, first block of the new access may either follow
|
|
|
|
|
* the last block of the previous access, or be equal to it.
|
|
|
|
|
*/
|
2024-04-09 01:13:27 +03:00
|
|
|
unsigned int dbs = zf->zf_dnode->dn_datablkshift;
|
|
|
|
|
uint64_t end_blkid = blkid + nblks;
|
2015-12-27 00:10:31 +03:00
|
|
|
for (zs = list_head(&zf->zf_stream); zs != NULL;
|
|
|
|
|
zs = list_next(&zf->zf_stream, zs)) {
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
if (blkid == zs->zs_blkid) {
|
2024-04-09 01:13:27 +03:00
|
|
|
goto hit;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
} else if (blkid + 1 == zs->zs_blkid) {
|
|
|
|
|
blkid++;
|
|
|
|
|
nblks--;
|
2024-04-09 01:13:27 +03:00
|
|
|
goto hit;
|
2010-05-29 00:45:14 +04:00
|
|
|
}
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
|
|
|
|
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
/*
|
2024-04-09 01:13:27 +03:00
|
|
|
* Find close enough prefetch stream. Access crossing stream position
|
|
|
|
|
* is a hit in its new part. Access ahead of stream position considered
|
|
|
|
|
* a hit for metadata prefetch, since we do not care about fill percent,
|
|
|
|
|
* or stored for future otherwise. Access behind stream position is
|
|
|
|
|
* silently ignored, since we already skipped it reaching fill percent.
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
*/
|
2024-04-09 01:13:27 +03:00
|
|
|
uint_t max_reorder = MIN((zfetch_max_reorder >> dbs) + 1, UINT16_MAX);
|
|
|
|
|
uint_t t = gethrestime_sec() - zfetch_max_sec_reap;
|
|
|
|
|
for (zs = list_head(&zf->zf_stream); zs != NULL;
|
|
|
|
|
zs = list_next(&zf->zf_stream, zs)) {
|
|
|
|
|
if (blkid > zs->zs_blkid) {
|
|
|
|
|
if (end_blkid <= zs->zs_blkid + max_reorder) {
|
|
|
|
|
if (!fetch_data) {
|
|
|
|
|
nblks = dmu_zfetch_hit(zs,
|
|
|
|
|
end_blkid - zs->zs_blkid);
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_stride);
|
|
|
|
|
goto future;
|
|
|
|
|
}
|
|
|
|
|
nblks = dmu_zfetch_future(zs, blkid, nblks);
|
|
|
|
|
if (nblks > 0)
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_stride);
|
|
|
|
|
else
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_future);
|
|
|
|
|
goto future;
|
|
|
|
|
}
|
|
|
|
|
} else if (end_blkid >= zs->zs_blkid) {
|
|
|
|
|
nblks -= zs->zs_blkid - blkid;
|
|
|
|
|
blkid += zs->zs_blkid - blkid;
|
|
|
|
|
goto hit;
|
|
|
|
|
} else if (end_blkid + max_reorder > zs->zs_blkid &&
|
|
|
|
|
(int)(zs->zs_atime - t) >= 0) {
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_past);
|
|
|
|
|
zs->zs_atime = gethrestime_sec();
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
}
|
|
|
|
|
|
2024-04-09 01:13:27 +03:00
|
|
|
/*
|
|
|
|
|
* This access is not part of any existing stream. Create a new
|
|
|
|
|
* stream for it unless we are at the end of file.
|
|
|
|
|
*/
|
|
|
|
|
if (end_blkid < maxblkid)
|
|
|
|
|
dmu_zfetch_stream_create(zf, end_blkid);
|
|
|
|
|
mutex_exit(&zf->zf_lock);
|
|
|
|
|
if (!have_lock)
|
|
|
|
|
rw_exit(&zf->zf_dnode->dn_struct_rwlock);
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_misses);
|
|
|
|
|
return (NULL);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
|
2024-04-09 01:13:27 +03:00
|
|
|
hit:
|
|
|
|
|
nblks = dmu_zfetch_hit(zs, nblks);
|
|
|
|
|
ZFETCHSTAT_BUMP(zfetchstat_hits);
|
|
|
|
|
|
|
|
|
|
future:
|
|
|
|
|
zs->zs_atime = gethrestime_sec();
|
|
|
|
|
|
|
|
|
|
/* Exit if we already prefetched for this position before. */
|
|
|
|
|
if (nblks == 0)
|
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
|
|
/* If the file is ending, remove the stream. */
|
|
|
|
|
end_blkid = zs->zs_blkid;
|
|
|
|
|
if (end_blkid >= maxblkid) {
|
|
|
|
|
dmu_zfetch_stream_remove(zf, zs);
|
|
|
|
|
out:
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_exit(&zf->zf_lock);
|
2019-07-08 23:18:50 +03:00
|
|
|
if (!have_lock)
|
|
|
|
|
rw_exit(&zf->zf_dnode->dn_struct_rwlock);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
return (NULL);
|
2015-12-27 00:10:31 +03:00
|
|
|
}
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2015-12-27 00:10:31 +03:00
|
|
|
/*
|
|
|
|
|
* This access was to a block that we issued a prefetch for on
|
2022-05-25 20:12:52 +03:00
|
|
|
* behalf of this stream. Calculate further prefetch distances.
|
2015-12-27 00:10:31 +03:00
|
|
|
*
|
2022-05-25 20:12:52 +03:00
|
|
|
* Start prefetch from the demand access size (nblks). Double the
|
|
|
|
|
* distance every access up to zfetch_min_distance. After that only
|
|
|
|
|
* if needed increase the distance by 1/8 up to zfetch_max_distance.
|
2023-03-02 02:27:40 +03:00
|
|
|
*
|
|
|
|
|
* Don't double the distance beyond single block if we have more
|
|
|
|
|
* than ~6% of ARC held by active prefetches. It should help with
|
|
|
|
|
* getting out of RAM on some badly mispredicted read patterns.
|
2015-12-27 00:10:31 +03:00
|
|
|
*/
|
2023-03-02 02:27:40 +03:00
|
|
|
unsigned int nbytes = nblks << dbs;
|
2022-05-25 20:12:52 +03:00
|
|
|
unsigned int pf_nblks;
|
2016-08-30 00:36:39 +03:00
|
|
|
if (fetch_data) {
|
2022-05-25 20:12:52 +03:00
|
|
|
if (unlikely(zs->zs_pf_dist < nbytes))
|
|
|
|
|
zs->zs_pf_dist = nbytes;
|
2023-03-02 02:27:40 +03:00
|
|
|
else if (zs->zs_pf_dist < zfetch_min_distance &&
|
|
|
|
|
(zs->zs_pf_dist < (1 << dbs) ||
|
|
|
|
|
aggsum_compare(&zfetch_sums.zfetchstat_io_active,
|
|
|
|
|
arc_c_max >> (4 + dbs)) < 0))
|
2022-05-25 20:12:52 +03:00
|
|
|
zs->zs_pf_dist *= 2;
|
|
|
|
|
else if (zs->zs_more)
|
|
|
|
|
zs->zs_pf_dist += zs->zs_pf_dist / 8;
|
|
|
|
|
zs->zs_more = B_FALSE;
|
|
|
|
|
if (zs->zs_pf_dist > zfetch_max_distance)
|
|
|
|
|
zs->zs_pf_dist = zfetch_max_distance;
|
2023-03-02 02:27:40 +03:00
|
|
|
pf_nblks = zs->zs_pf_dist >> dbs;
|
2016-08-30 00:36:39 +03:00
|
|
|
} else {
|
|
|
|
|
pf_nblks = 0;
|
|
|
|
|
}
|
2024-04-09 01:13:27 +03:00
|
|
|
if (zs->zs_pf_start < end_blkid)
|
|
|
|
|
zs->zs_pf_start = end_blkid;
|
|
|
|
|
if (zs->zs_pf_end < end_blkid + pf_nblks)
|
|
|
|
|
zs->zs_pf_end = end_blkid + pf_nblks;
|
2008-11-20 23:01:55 +03:00
|
|
|
|
2016-08-30 00:36:39 +03:00
|
|
|
/*
|
2022-05-25 20:12:52 +03:00
|
|
|
* Do the same for indirects, starting where we will stop reading
|
|
|
|
|
* data blocks (and the indirects that point to them).
|
2016-08-30 00:36:39 +03:00
|
|
|
*/
|
2022-05-25 20:12:52 +03:00
|
|
|
if (unlikely(zs->zs_ipf_dist < nbytes))
|
|
|
|
|
zs->zs_ipf_dist = nbytes;
|
|
|
|
|
else
|
|
|
|
|
zs->zs_ipf_dist *= 2;
|
|
|
|
|
if (zs->zs_ipf_dist > zfetch_max_idistance)
|
|
|
|
|
zs->zs_ipf_dist = zfetch_max_idistance;
|
2023-03-02 02:27:40 +03:00
|
|
|
pf_nblks = zs->zs_ipf_dist >> dbs;
|
2022-05-25 20:12:52 +03:00
|
|
|
if (zs->zs_ipf_start < zs->zs_pf_end)
|
|
|
|
|
zs->zs_ipf_start = zs->zs_pf_end;
|
|
|
|
|
if (zs->zs_ipf_end < zs->zs_pf_end + pf_nblks)
|
|
|
|
|
zs->zs_ipf_end = zs->zs_pf_end + pf_nblks;
|
2016-08-30 00:36:39 +03:00
|
|
|
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
zfs_refcount_add(&zs->zs_refs, NULL);
|
|
|
|
|
/* Count concurrent callers. */
|
|
|
|
|
zfs_refcount_add(&zs->zs_callers, NULL);
|
2019-07-25 21:57:58 +03:00
|
|
|
mutex_exit(&zf->zf_lock);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
|
|
|
|
|
if (!have_lock)
|
|
|
|
|
rw_exit(&zf->zf_dnode->dn_struct_rwlock);
|
|
|
|
|
return (zs);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void
|
2024-04-09 01:13:27 +03:00
|
|
|
dmu_zfetch_run(zfetch_t *zf, zstream_t *zs, boolean_t missed,
|
|
|
|
|
boolean_t have_lock)
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
{
|
|
|
|
|
int64_t pf_start, pf_end, ipf_start, ipf_end;
|
|
|
|
|
int epbs, issued;
|
|
|
|
|
|
|
|
|
|
if (missed)
|
|
|
|
|
zs->zs_missed = missed;
|
2016-08-30 00:36:39 +03:00
|
|
|
|
|
|
|
|
/*
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
* Postpone the prefetch if there are more concurrent callers.
|
|
|
|
|
* It happens when multiple requests are waiting for the same
|
|
|
|
|
* indirect block. The last one will run the prefetch for all.
|
2016-08-30 00:36:39 +03:00
|
|
|
*/
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
if (zfs_refcount_remove(&zs->zs_callers, NULL) != 0) {
|
|
|
|
|
/* Drop reference taken in dmu_zfetch_prepare(). */
|
|
|
|
|
if (zfs_refcount_remove(&zs->zs_refs, NULL) == 0)
|
|
|
|
|
dmu_zfetch_stream_fini(zs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-08-30 00:36:39 +03:00
|
|
|
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
mutex_enter(&zf->zf_lock);
|
|
|
|
|
if (zs->zs_missed) {
|
2022-05-25 20:12:52 +03:00
|
|
|
pf_start = zs->zs_pf_start;
|
|
|
|
|
pf_end = zs->zs_pf_start = zs->zs_pf_end;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
} else {
|
|
|
|
|
pf_start = pf_end = 0;
|
|
|
|
|
}
|
2022-05-25 20:12:52 +03:00
|
|
|
ipf_start = zs->zs_ipf_start;
|
|
|
|
|
ipf_end = zs->zs_ipf_start = zs->zs_ipf_end;
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
mutex_exit(&zf->zf_lock);
|
|
|
|
|
ASSERT3S(pf_start, <=, pf_end);
|
|
|
|
|
ASSERT3S(ipf_start, <=, ipf_end);
|
|
|
|
|
|
|
|
|
|
epbs = zf->zf_dnode->dn_indblkshift - SPA_BLKPTRSHIFT;
|
|
|
|
|
ipf_start = P2ROUNDUP(ipf_start, 1 << epbs) >> epbs;
|
|
|
|
|
ipf_end = P2ROUNDUP(ipf_end, 1 << epbs) >> epbs;
|
|
|
|
|
ASSERT3S(ipf_start, <=, ipf_end);
|
|
|
|
|
issued = pf_end - pf_start + ipf_end - ipf_start;
|
|
|
|
|
if (issued > 1) {
|
|
|
|
|
/* More references on top of taken in dmu_zfetch_prepare(). */
|
2023-06-05 21:51:44 +03:00
|
|
|
zfs_refcount_add_few(&zs->zs_refs, issued - 1, NULL);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
} else if (issued == 0) {
|
|
|
|
|
/* Some other thread has done our work, so drop the ref. */
|
|
|
|
|
if (zfs_refcount_remove(&zs->zs_refs, NULL) == 0)
|
|
|
|
|
dmu_zfetch_stream_fini(zs);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2023-03-02 02:27:40 +03:00
|
|
|
aggsum_add(&zfetch_sums.zfetchstat_io_active, issued);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
|
|
|
|
|
if (!have_lock)
|
|
|
|
|
rw_enter(&zf->zf_dnode->dn_struct_rwlock, RW_READER);
|
|
|
|
|
|
|
|
|
|
issued = 0;
|
|
|
|
|
for (int64_t blk = pf_start; blk < pf_end; blk++) {
|
|
|
|
|
issued += dbuf_prefetch_impl(zf->zf_dnode, 0, blk,
|
2022-12-22 23:10:24 +03:00
|
|
|
ZIO_PRIORITY_ASYNC_READ, 0, dmu_zfetch_done, zs);
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
for (int64_t iblk = ipf_start; iblk < ipf_end; iblk++) {
|
2020-09-28 03:08:38 +03:00
|
|
|
issued += dbuf_prefetch_impl(zf->zf_dnode, 1, iblk,
|
2022-12-22 23:10:24 +03:00
|
|
|
ZIO_PRIORITY_ASYNC_READ, 0, dmu_zfetch_done, zs);
|
2016-08-30 00:36:39 +03:00
|
|
|
}
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
|
2019-07-08 23:18:50 +03:00
|
|
|
if (!have_lock)
|
|
|
|
|
rw_exit(&zf->zf_dnode->dn_struct_rwlock);
|
2020-09-28 03:08:38 +03:00
|
|
|
|
|
|
|
|
if (issued)
|
|
|
|
|
ZFETCHSTAT_ADD(zfetchstat_io_issued, issued);
|
2008-11-20 23:01:55 +03:00
|
|
|
}
|
2010-08-26 22:49:16 +04:00
|
|
|
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
void
|
|
|
|
|
dmu_zfetch(zfetch_t *zf, uint64_t blkid, uint64_t nblks, boolean_t fetch_data,
|
|
|
|
|
boolean_t missed, boolean_t have_lock)
|
|
|
|
|
{
|
|
|
|
|
zstream_t *zs;
|
|
|
|
|
|
|
|
|
|
zs = dmu_zfetch_prepare(zf, blkid, nblks, fetch_data, have_lock);
|
|
|
|
|
if (zs)
|
2024-04-09 01:13:27 +03:00
|
|
|
dmu_zfetch_run(zf, zs, missed, have_lock);
|
Split dmu_zfetch() speculation and execution parts
To make better predictions on parallel workloads dmu_zfetch() should
be called as early as possible to reduce possible request reordering.
In particular, it should be called before dmu_buf_hold_array_by_dnode()
calls dbuf_hold(), which may sleep waiting for indirect blocks, waking
up multiple threads same time on completion, that can significantly
reorder the requests, making the stream look like random. But we
should not issue prefetch requests before the on-demand ones, since
they may get to the disks first despite the I/O scheduler, increasing
on-demand request latency.
This patch splits dmu_zfetch() into two functions: dmu_zfetch_prepare()
and dmu_zfetch_run(). The first can be executed as early as needed.
It only updates statistics and makes predictions without issuing any
I/Os. The I/O issuance is handled by dmu_zfetch_run(), which can be
called later when all on-demand I/Os are already issued. It even
tracks the activity of other concurrent threads, issuing the prefetch
only when _all_ on-demand requests are issued.
For many years it was a big problem for storage servers, handling
deeper request queues from their clients, having to either serialize
consequential reads to make ZFS prefetcher usable, or execute the
incoming requests as-is and get almost no prefetch from ZFS, relying
only on deep enough prefetch by the clients. Benefits of those ways
varied, but neither was perfect. With this patch deeper queue
sequential read benchmarks with CrystalDiskMark from Windows via
iSCSI to FreeBSD target show me much better throughput with almost
100% prefetcher hit rate, comparing to almost zero before.
While there, I also removed per-stream zs_lock as useless, completely
covered by parent zf_lock. Also I reused zs_blocks refcount to track
zf_stream linkage of the stream, since I believe previous zs_fetch ==
NULL check in dmu_zfetch_stream_done() was racy.
Delete prefetch streams when they reach ends of files. It saves up
to 1KB of RAM per file, plus reduces searches through the stream list.
Block data prefetch (speculation and indirect block prefetch is still
done since they are cheaper) if all dbufs of the stream are already
in DMU cache. First cache miss immediately fires all the prefetch
that would be done for the stream by that time. It saves some CPU
time if same files within DMU cache capacity are read over and over.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Adam Moss <c@yotes.com>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Alexander Motin <mav@FreeBSD.org>
Sponsored-By: iXsystems, Inc.
Closes #11652
2021-03-20 08:56:11 +03:00
|
|
|
}
|
|
|
|
|
|
2019-09-06 00:49:49 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfs_prefetch_, disable, INT, ZMOD_RW,
|
|
|
|
|
"Disable all ZFS prefetching");
|
2011-05-04 02:09:28 +04:00
|
|
|
|
2019-09-06 00:49:49 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, max_streams, UINT, ZMOD_RW,
|
|
|
|
|
"Max number of streams per zfetch");
|
2011-05-04 02:09:28 +04:00
|
|
|
|
2019-09-06 00:49:49 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, min_sec_reap, UINT, ZMOD_RW,
|
|
|
|
|
"Min time before stream reclaim");
|
2011-05-04 02:09:28 +04:00
|
|
|
|
2022-05-25 20:12:52 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, max_sec_reap, UINT, ZMOD_RW,
|
|
|
|
|
"Max time before stream delete");
|
|
|
|
|
|
|
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, min_distance, UINT, ZMOD_RW,
|
|
|
|
|
"Min bytes to prefetch per stream");
|
|
|
|
|
|
2019-09-06 00:49:49 +03:00
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, max_distance, UINT, ZMOD_RW,
|
2020-10-13 19:32:34 +03:00
|
|
|
"Max bytes to prefetch per stream");
|
|
|
|
|
|
|
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, max_idistance, UINT, ZMOD_RW,
|
|
|
|
|
"Max bytes to prefetch indirects for per stream");
|
2024-04-09 01:13:27 +03:00
|
|
|
|
|
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, max_reorder, UINT, ZMOD_RW,
|
|
|
|
|
"Max request reorder distance within a stream");
|
|
|
|
|
|
|
|
|
|
ZFS_MODULE_PARAM(zfs_prefetch, zfetch_, hole_shift, UINT, ZMOD_RW,
|
|
|
|
|
"Max log2 fraction of holes in a stream");
|