Remove OBJT_SWAP_TMPFS, dynamically register pager type for tmpfs on vfs_init
Details
- Reviewers
alc markj mjg - Commits
- rG28bc23ab92ce: tmpfs: dynamically register tmpfs pager
rG7079449b0b56: sys/vm: remove several other uses of OBJT_SWAP_TMPFS
rGb730fd30b78f: vm: Add KPI to dynamically register pagers
rG3e7a11ca21f3: vm_object_set_memattr(): handle all object types without listing them explicitly
rG8b99833ac253: procfs_map: switch to use vm_object_kvme_type
rG00a3fe968b84: vm_object_kvme_type(): reimplement by embedding kvme_type into pagerops
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
Is the functionality really worth it? There are also no provisions to refcount pager users, so there is no way to indicate it can't be safely unloaded. tmpfs is enabled in GENERIC, so by default the fuctionality wont be used.
Even if the patch is to go in, perhaps it would be sufficient to skip automatic registration and explicitly enumerate all supported pager types to save on some complexity.
My $0,03.
For tmpfs it is clearly the presence of mounts that is equal to presence of users.
GENERIC is not the end of the world, for instance all my kernels do not include tmpfs (I use some kind of MINIMAL, but less than it)
Overall, dyn registration incurs zero runtime overhead, and makes it easier to create new types of pagers. Although it is non-trivial to write correct pager, I will not be surprised if something new appears there once we make it less troublesome. One immediate candidate would be to make largepage shm use real pager instead of patching phys.
Even if the patch is to go in, perhaps it would be sufficient to skip automatic registration and explicitly enumerate all supported pager types to save on some complexity.
I think that this change provides a useful cleanup of the VM system. As noted it makes it easier to create new types of pagers.
sys/fs/procfs/procfs_map.c | ||
---|---|---|
168 | So what should be done here? Can vm_object_kvme_type() be used? |
sys/fs/tmpfs/tmpfs_subr.c | ||
---|---|---|
117 | Why can't handle be used instead of the pager-specific field? |
sys/fs/tmpfs/tmpfs_subr.c | ||
---|---|---|
117 | Correct use of the 'handle' field for non-anon objects is to pass handle to vm_pager_allocate(), which registers the object on the list of named pager-owned objects. Several places in vm/ assume that non-anon named object == obj->handle != NULL. So there are problems.
The only meaningful and conforming value we can assign to handle there is tmpfs_node. But we do not need neither that, nor 'named swap object' semantic. |