Use atomics for paging in progress.

[jeff]

Summary

This ultimately will allow us to drop the object lock in more cases. This diff just sets things up so this is possible.

pip_wait is simply a barrier. If the caller doesn't somehow enforce that no new I/O can be started before calling pip_wait() it can become non-zero immediately after returning. The call does still guarantee that pip reached zero at some point.

We use pip when collapsing objects and in this case the object lock will guarantee that no new faults or pageouts can occur. The other use is in vfs which simply wants to know that a fsync completed. Here the vnode lock is held and ensures that no new I/O can start.

[markj]

sys/vm/vm_object.c

785 ↗

(On Diff #60961)

Why did you move this block?

[jeff]

sys/vm/vm_object.c

785 ↗

(On Diff #60961)

It may not be 100% required but it was non-nonsensical. Since the buffer cache is going to increment paging in progress via putpages in vm_object_page_clean this place gives a more final answer.

[kib]

Note that for devfs vnodes the vnode lock is often not held when writes are started. This is esp. true when metadata io is initiated by UFS.