Files
mirror_zfs/include/sys
Matthew Ahrens 1dc32a67e9 Improve zfs send performance by bypassing the ARC
When doing a zfs send on a dataset with small recordsize (e.g. 8K),
performance is dominated by the per-block overheads.  This is especially
true with `zfs send --compressed`, which further reduces the amount of
data sent, for the same number of blocks.  Several threads are involved,
but the limiting factor is the `send_prefetch` thread, which is 100% on
CPU.

The main job of the `send_prefetch` thread is to issue zio's for the
data that will be needed by the main thread.  It does this by calling
`arc_read(ARC_FLAG_PREFETCH)`.  This has an immediate cost of creating
an arc_hdr, which takes around 14% of one CPU.  It also induces later
costs by other threads:

 * Since the data was only prefetched, dmu_send()->dmu_dump_write() will
   need to call arc_read() again to get the data.  This will have to
   look up the arc_hdr in the hash table and copy the data from the
   scatter ABD in the arc_hdr to a linear ABD in arc_buf.  This takes
   27% of one CPU.

 * dmu_dump_write() needs to arc_buf_destroy()  This takes 11% of one
   CPU.

 * arc_adjust() will need to evict this arc_hdr, taking about 50% of one
   CPU.

All of these costs can be avoided by bypassing the ARC if the data is
not already cached.  This commit changes `zfs send` to check for the
data in the ARC, and if it is not found then we directly call
`zio_read()`, reading the data into a linear ABD which is used by
dmu_dump_write() directly.

The performance improvement is best expressed in terms of how many
blocks can be processed by `zfs send` in one second.  This change
increases the metric by 50%, from ~100,000 to ~150,000.  When the amount
of data per block is small (e.g. 2KB), there is a corresponding
reduction in the elapsed time of `zfs send >/dev/null` (from 86 minutes
to 58 minutes in this test case).

In addition to improving the performance of `zfs send`, this change
makes `zfs send` not pollute the ARC cache.  In most cases the data will
not be reused, so this allows us to keep caching useful data in the MRU
(hit-once) part of the ARC.

Reviewed-by: Paul Dagnelie <pcd@delphix.com>
Reviewed-by: Serapheim Dimitropoulos <serapheim@delphix.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Matthew Ahrens <mahrens@delphix.com>
Closes #10067
2020-03-10 10:51:04 -07:00
..
2020-03-04 15:07:11 -08:00
2019-08-30 09:53:15 -07:00
2019-03-29 09:13:20 -07:00
2019-10-09 10:36:03 -07:00
2019-10-09 10:36:03 -07:00
2019-07-26 10:54:14 -07:00
2019-07-26 10:54:14 -07:00
2019-06-19 09:48:12 -07:00
2019-10-11 10:13:21 -07:00
2020-02-05 11:08:44 -08:00
2019-06-19 14:54:02 -07:00
2019-06-19 09:48:12 -07:00
2019-07-26 10:54:14 -07:00
2019-06-19 09:48:12 -07:00
2020-01-10 10:16:58 -08:00
2019-06-19 09:48:12 -07:00
2019-07-25 11:57:58 -07:00
2020-02-24 15:38:22 -08:00
2020-02-11 13:19:17 -08:00
2019-06-19 09:48:12 -07:00
2019-06-24 16:44:01 -07:00
2019-07-26 10:54:14 -07:00
2019-07-26 10:54:14 -07:00
2013-11-04 11:17:48 -08:00
2019-08-30 09:53:15 -07:00
2017-12-07 10:28:50 -08:00
2017-10-11 16:54:48 -04:00
2019-11-01 10:41:03 -07:00
2018-05-29 16:00:33 -07:00
2018-10-03 15:30:55 -07:00
2019-06-19 09:48:12 -07:00
2019-09-12 13:33:44 -07:00
2019-10-31 10:38:03 -07:00
2019-09-27 10:46:28 -07:00
2019-08-30 09:53:15 -07:00
2019-07-16 10:11:49 -07:00
2019-07-16 10:11:49 -07:00
2019-08-30 09:53:15 -07:00
2017-07-13 13:54:00 -04:00
2013-11-04 10:55:25 -08:00
2020-02-27 09:31:02 -08:00
2019-03-29 09:13:20 -07:00
2020-01-23 11:01:24 -08:00
2019-03-29 09:13:20 -07:00
2019-11-27 10:15:01 -08:00
2019-06-12 13:13:09 -07:00
2018-02-08 15:28:18 -08:00
2018-02-08 15:28:18 -08:00
2019-10-25 13:38:37 -07:00
2018-05-29 16:00:33 -07:00
2019-11-01 10:37:33 -07:00
2018-02-13 14:54:54 -08:00
2018-09-06 21:44:52 -07:00
2019-06-10 11:48:42 -07:00
2019-11-21 09:32:57 -08:00
2017-03-29 12:24:51 -07:00
2019-08-30 09:53:15 -07:00
2019-03-29 09:13:20 -07:00
2020-02-10 14:00:05 -08:00
2019-07-26 10:54:14 -07:00
2019-11-01 10:37:33 -07:00