Page MenuHomeFreeBSD

vfs: fix vnlru marker handling for filtered/unfiltered cases
ClosedPublic

Authored by mjg on Mar 18 2021, 2:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 7, 7:04 PM
Unknown Object (File)
Dec 23 2023, 11:03 AM
Unknown Object (File)
Dec 12 2023, 9:49 PM
Unknown Object (File)
Sep 11 2023, 1:25 PM
Unknown Object (File)
Aug 27 2023, 2:40 PM
Unknown Object (File)
Aug 16 2023, 9:22 AM
Unknown Object (File)
Aug 16 2023, 7:36 AM
Unknown Object (File)
Jul 7 2023, 11:15 PM
Subscribers

Details

Summary

The global list has a marker with an invariant that free vnodes are placed somewhere past that. A caller which performs filtering (like ZFS) can move said marker all the way to the end, across free vnodes which don't match. Then a caller which does not perform filtering will fail to find them. This makes vn_alloc_hard sleep for 1 second instead of reclaiming, resulting in significant stalls.

Fix the problem by requiring an explicit marker by callers which do filtering.

As a temporary measure extend vnlru_free to restart if it fails to reclaim anything.

MFC: immediately

Test Plan

Tested by the user which reported the problem here https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079173.html

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mjg requested review of this revision.Mar 18 2021, 2:08 PM
mjg edited the summary of this revision. (Show Details)
mjg edited the test plan for this revision. (Show Details)
sys/kern/vfs_subr.c
1302

Your logic to reset the marker from head only triggers if there were no vnode (try)reclaimed at all. Should it occur even if some vnode was tryrecycled, but target not met?

sys/kern/vfs_subr.c
1302

I don't think it's worthwhile. In base only zfs can run into the problem, so addressing this would be a nop for this case. For any other case, if there are real problems there will be repeated calls and they will make progress.

1302

.. since the marker got wrapped around

This revision is now accepted and ready to land.Mar 18 2021, 2:50 PM