Reviewed by: Matt Ahrens <mahr...@delphix.com>
Reviewed by: Serapheim Dimitropoulos <seraph...@delphix.com>
Reviewed by: Pavel Zakharov <pavel.zakha...@delphix.com>
Reviewed by: Dan Kimmel <dan.kim...@delphix.com>
`arc_reclaim_thread()` calls `arc_adjust()` after calling
`arc_kmem_reap_now()`; `arc_adjust()` signals `arc_get_data_buf()` to
indicate that we may no longer be `arc_is_overflowing()`.
The problem is, `arc_kmem_reap_now()` can take several seconds to
complete, has no impact on `arc_is_overflowing()`, but due to how the
code is structured, can impact how long the ARC will remain in the
`arc_is_overflowing()` state.
The fix is to use seperate threads to:
1. keep `arc_size` under `arc_c`, by calling `arc_adjust()`, which
improves `arc_is_overflowing()`
2. keep enough free memory in the system, by calling
`arc_kmem_reap_now()` plus `arc_shrink()`, which improves
`arc_available_memory()`.
Upstream bugs: DLPX-44270, DLPX-50734, DLPX-46652, DLPX-49690
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/486
-- Commit Summary --
* 0000 arc_reclaim_thread has 2 jobs
-- File Changes --
M usr/src/uts/common/Makefile.files (3)
M usr/src/uts/common/fs/zfs/arc.c (305)
A usr/src/uts/common/fs/zfs/sys/zthr.h (55)
A usr/src/uts/common/fs/zfs/zthr.c (343)
-- Patch Links --
https://github.com/openzfs/openzfs/pull/486.patch
https://github.com/openzfs/openzfs/pull/486.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/486
------------------------------------------
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/Tf18bbbd46b0af4a7-M607862356063ffb58d25897d
Powered by Topicbox: https://topicbox.com
