Reviewed by: Paul Dagnelie <[email protected]>
Reviewed by: Matthew Ahrens <[email protected]>
Reviewed by: Sebastien Roy <[email protected]>
When the system runs low on memory it will invoke kmem_reap() to reap
all the kmem caches. The reaping processes each cache serially, first
calling the reclaim callback. We have seen a couple of caches where the
reclaim callback can block the reaping thread for a significant amount
of time. The stack looks like this:
ffffff00d2417c40 SLEEP RWLOCK 1
swtch+0x141
turnstile_block+0x262
rw_enter_sleep+0x21d
exi_cache_trim+0x40
exi_cache_reclaim+0x40
kmem_cache_reap+0x3b
taskq_thread+0x2d0
thread_start+8
Since the reaping is treated like a queue it's not possible to reap any
other caches until we're finished reclaiming the exi_cache[s]. The
exi_cache_trim() function is trying to grab the rw lock as writer and
has to wait for all readers to finish processing any work. The problem
is that the threads holding the rw lock as reader may end up getting
stuck waiting on an allocation. It would make more sense to make this a
best effort attempt and only process the reclaim if we're able to obtain
the rw lock as writer.
The reclaim callback should call rw_tryenter() instead of blocking. This
will ensure that we don't block the main thread which is trying to free
memory.
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/38
-- Commit Summary --
* 6458 kmem reap thread gets blocked in reclaim callback
-- File Changes --
M usr/src/uts/common/fs/nfs/nfs_auth.c (18)
-- Patch Links --
https://github.com/openzfs/openzfs/pull/38.patch
https://github.com/openzfs/openzfs/pull/38.diff
---
Reply to this email directly or view it on GitHub:
https://github.com/openzfs/openzfs/pull/38
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
