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>
Reviewed by: Paul Dagnelie <p...@delphix.com>
Following the fix for 9018 (Replace kmem_cache_reap_now() with
kmem_cache_reap_soon), the arc_reclaim_thread() no longer blocks while
reaping. However, the code is still confusing and error-prone, because
this thread has two responsibilities. We should instead separate this
into two threads each with their own responsibility:
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()`.
Furthermore, we can use the zthr infrastructure to separate the "should
we do something" from "do it" parts of the logic, and normalize the
start up / shut down of the threads.
Upstream bugs: DLPX-44270, DLPX-50734, DLPX-46652, DLPX-49690, DLPX-56784
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/590
-- Commit Summary --
* 9284 arc_reclaim_thread has 2 jobs
-- File Changes --
M usr/src/uts/common/fs/zfs/arc.c (375)
M usr/src/uts/common/fs/zfs/sys/zthr.h (4)
M usr/src/uts/common/fs/zfs/zthr.c (28)
-- Patch Links --
https://github.com/openzfs/openzfs/pull/590.patch
https://github.com/openzfs/openzfs/pull/590.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/590
------------------------------------------
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/discussions/T9a4d185b31cf8b80-M0bbec1ba3aa680924034ef68
Delivery options: https://openzfs.topicbox.com/groups
