Is there a reason we're not using accessors?

This doesn't really need to be defined in every pmap. I believe they all support it now.

Again why not an accessor? I think I don't like the ->a. everywhere and moving accesses into an accessor makes it less likely for someone to modify a field directly in error.

I would resort to group assignments.

Does every arch support atomic_load_16 now?

If this is available everywhere we should update the atomic man page.

In an earlier version I added vm_page_aflags_load() but thought it was too verbose. We cannot #define aflags (it's a common variable name) and I dislike the practice of #defining field names. I can use vm_page_aflags_load() if you prefer or can implement a different suggestion.

We already have vm_page_queue(), I will convert this line to use.

There should really be no direct accesses of a.queue outside of vm_page.c and maybe vm_pageout.c, so I do not see a reason to add a direct accessor. (vm_page_queue() is higher-level.)

Yes, they all always have. It's 16-bit atomic updates that are not completely supported.

AFAIK it does not claim anywhere that atomic_load_(8|16) cannot be used in MI code.

I would say 'state accessed atomically'

This should be updated with the new name and size.

I had considered that too but we don't have anything like it in the tree, and it's not immediately obvious whether vm_page_aflag() would return true only if all of the specified bits are set.

This whole section will be removed in the next patch in this series: the use of a structure allows the compiler to generate these offsets.