]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
9284 arc_reclaim_thread has 2 jobs
authorAlexander Motin <mav@FreeBSD.org>
Mon, 30 Jul 2018 19:44:14 +0000 (19:44 +0000)
committerAlexander Motin <mav@FreeBSD.org>
Mon, 30 Jul 2018 19:44:14 +0000 (19:44 +0000)
commitec66f8a6e32dbd4d693c47cc9625de866bc1307c
treedacecd6c124f83f41b3135fa24b60805d50f1741
parenta622bac50f080182269712eb65399da717ba0aca
9284 arc_reclaim_thread has 2 jobs

`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()`.

illumos/illumos-gate@de753e34f9c399037936e8bc547d823bba9d4b0d

Reviewed by: Matt Ahrens <mahrens@delphix.com>
Reviewed by: Serapheim Dimitropoulos <serapheim@delphix.com>
Reviewed by: Pavel Zakharov <pavel.zakharov@delphix.com>
Reviewed by: Dan Kimmel <dan.kimmel@delphix.com>
Reviewed by: Paul Dagnelie <pcd@delphix.com>
Reviewed by: Dan McDonald <danmcd@joyent.com>
Reviewed by: Tim Kordas <tim.kordas@joyent.com>
Approved by: Garrett D'Amore <garrett@damore.org>
Author: Brad Lewis <brad.lewis@delphix.com>
uts/common/fs/zfs/arc.c
uts/common/fs/zfs/sys/zthr.h
uts/common/fs/zfs/zthr.c