[wip] extend MNT_VNODE_FOREACH macro with callback argument and use it to filter vnodes for tmpfs mtime

[mjg]

Summary

Note this is just a proposal.

Currently tmpfs scans the entire vnode list looking for potential vnodes which need the update. When running with poudriere this translated to hundreds of thousands of vnodes scanned per second due to hundreds of mount points. While not doing it in the first place would be best, what follows is a simple bandaid.

At the very least the code can be augmented to pre-filter vnodes without taking the interlock. Checking with dtrace reveals there almost no vnodes need the treatment, thus this avoids a lot of locking.

I think this is perfectly safe since vm objects are type-stable. A cast through volatile read is performed to make sure the pointer is only read once.

One thing which may need to be improved here is the total lock hold time. Perhaps it can be relocked every n vnodes or if should_yield indicates it.

[kib]

I do not object against this.

I do not see how could you avoid scanning vnodes, mtime updates from the mmaped writes to the file is the POSIX-mandated feature and users complained about lack of it.

sys/fs/tmpfs/tmpfs_vfsops.c

153

I assume this knob is added only for the measures ?

[mjg]

In D20243#436232, @kib wrote:

I do not see how could you avoid scanning vnodes, mtime updates from the mmaped writes to the file is the POSIX-mandated feature and users complained about lack of it.

I don't know if feasible, but perhaps each tmpfs mount point can maintain a total count of vnodes with mappings for writing. Then if the count is 0 the scan can be avoided entirely.

Regardless, I noted some form of throttling may be necessary. I found the patch to be causing stalls sometimes. Will have to add logic to push marker around and relock periodically.

sys/fs/tmpfs/tmpfs_vfsops.c

153

yes

[mjg]

This will be fixed differently to not require this scan.