Changeset View
Standalone View
sys/kern/vfs_subr.c
Show First 20 Lines • Show All 1,304 Lines • ▼ Show 20 Lines | for (mp = TAILQ_FIRST(&mountlist); mp != NULL; mp = nmp) { | ||||
continue; | continue; | ||||
} | } | ||||
done += vlrureclaim(mp, reclaim_nc_src, trigger); | done += vlrureclaim(mp, reclaim_nc_src, trigger); | ||||
mtx_lock(&mountlist_mtx); | mtx_lock(&mountlist_mtx); | ||||
nmp = TAILQ_NEXT(mp, mnt_list); | nmp = TAILQ_NEXT(mp, mnt_list); | ||||
vfs_unbusy(mp); | vfs_unbusy(mp); | ||||
} | } | ||||
mtx_unlock(&mountlist_mtx); | mtx_unlock(&mountlist_mtx); | ||||
if (onumvnodes > desiredvnodes && numvnodes <= desiredvnodes) | if (onumvnodes > desiredvnodes && numvnodes <= desiredvnodes) | ||||
uma_reclaim(); | uma_reclaim(UMA_RECLAIM_DRAIN); | ||||
jeff: I'm confused about this. Why are we reclaiming from all zones after we reclaim some vnodes? | |||||
Not Done Inline ActionsHmm, it was added somewhat recently, in r291244. I don't know that we can assume regular grooming is going be happening concurrent to this? I agree that trimming is probably sufficient, especially in the absence of memory pressure. markj: Hmm, it was added somewhat recently, in r291244. I don't know that we can assume regular… | |||||
Not Done Inline ActionsI find this somewhat concerning. Perhaps we can get kib to comment. Again it's not your regression to fix but this really looks like overkill to me. jeff: I find this somewhat concerning. Perhaps we can get kib to comment. Again it's not your… | |||||
Not Done Inline ActionsIf we exceeded the vnode limit, and then flushed number of vnodes back to under it, we certainly could have overuse of the related zones. I do not remember was that uma_reclaim() call added by the original bde patch, or was it added after pho tests demonstrated the need. I do not object against less significant reclaim (TRIM in the patch terminology). kib: If we exceeded the vnode limit, and then flushed number of vnodes back to under it, we… | |||||
Not Done Inline ActionsI will ask Peter to test this version, which just trims the caches. markj: I will ask Peter to test this version, which just trims the caches. | |||||
Not Done Inline ActionsAFAIR the problems were with ZFS. UFS was relatively ok. kib: AFAIR the problems were with ZFS. UFS was relatively ok. | |||||
Not Done Inline ActionsThat makes sense given ZFS' heavy usage of UMA for large buffers. FWIW, earlier versions of this patch were tested by some ZFS users who reported seeing stalls when uma_reclaim() was called regularly by the page daemon. markj: That makes sense given ZFS' heavy usage of UMA for large buffers. FWIW, earlier versions of… | |||||
if (done == 0) { | if (done == 0) { | ||||
if (force == 0 || force == 1) { | if (force == 0 || force == 1) { | ||||
force = 2; | force = 2; | ||||
continue; | continue; | ||||
} | } | ||||
if (force == 2) { | if (force == 2) { | ||||
force = 3; | force = 3; | ||||
continue; | continue; | ||||
▲ Show 20 Lines • Show All 4,337 Lines • Show Last 20 Lines |
I'm confused about this. Why are we reclaiming from all zones after we reclaim some vnodes? Presumably a bunch of zones related to vfs now have some free memory. This should be a TRIM at most and now that we have more regular grooming I think it could be omitted entirely.