I think these bits are no longer needed.

Name it vm_object_is_active() and put it into vm/vm_object.h + vm/vm_object.c.

Some time ago the code managing shadow chains was refactored and changed so that only OBJ_ANON objects maintain a list of shadowing objects (and shadow_count). Doesn't this mean that vp->v_object->shadow_count is always 0, i.e., the use of this function disables the optimization?

Oh, indeed, I forgot about OBJ_ANON. But this breaks vm_meter at least.

I think shadow_count maintenance should be restored, perhaps in lock-less manner for objects that do not need to maintain shadow_list. I will do that.

In fact I do not understand why it is sufficient to check ref_count == shadow_count. Consider a file with two copy-on-write mappings, where each mapping has been written to at least once. Then the vnode's VM object has ref_count == shadow_count == 2 (assuming shadow count is maintained). Suppose a process updates the last page in the mappings with a write(). I would expect that write to be visible via either of the mappings, assuming that that page had not already been copied.

I do not believe this case was ever specified to work only that way. For instance, there might be one more object in the chain, and it might have the written page shadowed. I remember Alan mentioned that real Mach VM contained something that ensured that shadowed mappings only see the state of the backing objects at the moment of shadowing, but in FreeBSD it was removed.

(In my example there is no need for two CoW mappings; I was thinking of object collapse that but that's not relevant here.)

IMO the behaviour in this case should be determined by the VM system, not by individual filesystems, and other filesystems will make the write visible to the shadowing mappings, I believe.

I wonder if NFS could instead use the same mechanism that ZFS does to maintain DMU<->ARC consistency, i.e. update_pages(), which locklessly looks up a page at each index in the written range to see if it needs to be updated. OTOH, ZFS uses an internal rangelock to synchronize VOP_WRITE with VOP_GETPAGES, whereas I cannot see anything equivalent in the NFS client.

With the VM object lock held we could simply look for resident pages in the written range and write directly to the server if none are found, no?

Of course there is no such mechanism for NFS, because NFS normally uses buffer cache, and relies on the normal coherence of buffer cache and page cache. It is this specific hack/optimization for O_APPEND, created as a reaction to a deficiency in the NFS wire protocol, that breaks the coherency.

I believe that looking for the pages would be not that simple, because pages can be partially valid for NFS (another optimization to avoid extending transfers over wire to fill whole pages). And then all that complications are rather pointless because next operation after our write would detect changed mtime and invalidate the cache anyway.