Page MenuHomeFreeBSD

Use atomics for paging in progress.

Authored by jeff on Aug 18 2019, 8:50 AM.



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.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jeff created this revision.Aug 18 2019, 8:50 AM
jeff edited the summary of this revision. (Show Details)Aug 18 2019, 8:54 AM
jeff added reviewers: kib, alc, markj.
markj added inline comments.Mon, Aug 19, 4:04 PM
785 ↗(On Diff #60961)

Why did you move this block?

jeff added inline comments.Mon, Aug 19, 5:56 PM
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 added a comment.Mon, Aug 19, 6:38 PM

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.

markj accepted this revision.Mon, Aug 19, 9:32 PM
This revision is now accepted and ready to land.Mon, Aug 19, 9:32 PM