Page MenuHomeFreeBSD

Add KPI to dynamically register pager type
ClosedPublic

Authored by kib on May 7 2021, 8:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 12, 11:11 PM
Unknown Object (File)
Tue, Dec 10, 7:05 PM
Unknown Object (File)
Fri, Nov 22, 11:27 PM
Unknown Object (File)
Nov 20 2024, 6:15 AM
Unknown Object (File)
Nov 15 2024, 11:39 PM
Unknown Object (File)
Nov 14 2024, 9:10 PM
Unknown Object (File)
Nov 5 2024, 1:53 PM
Unknown Object (File)
Oct 31 2024, 8:09 PM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib requested review of this revision.May 7 2021, 8:08 PM
kib created this revision.

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.

In D30168#677456, @mjg wrote:

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.

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?

kib marked an inline comment as done.

Implement forgotten chunk in pseudofs_map.

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.

  1. We do not need the name for tmpfs objects, we never look up object by handle because we have node.
  2. Handle may become NULL when the vnode reclaimed, and assigned back some different non-NULL value when vnode recreated.

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.

This revision is now accepted and ready to land.May 10 2021, 8:44 PM