Fix the background laundering mechanism.

[markj]

Summary

We used to use the number of inactive queue scans as a measure of how
many clean pages were being reclaimed by the page daemon. This was used
to decide how often to launder a small number of dirty pages. With r329882, we
now scan the inactive queue more frequently, freeing a smaller number of
pages each time. Thus, the number of scans isn't as useful a metric and
we now launder too often.

Rather than counting scans, just count the total number of clean pages
freed during inactive queue scans. The laundry thread adds this value
into an accumulator which gets cleared once the background laundering
threshold is reached. This way we consider only the number of pages
freed rather than the number of scans.

[kib]

sys/vm/vm_pageout.c

946 ↗

(On Diff #40846)

Using uint64 sounds unnatural for me. Why not use longs ? I doubt that we can accumulate so many pages from the work that it overflows ulong on 32bits.

[markj]

sys/vm/vm_pageout.c

946 ↗

(On Diff #40846)

I considered doing that, but:

• In the case of ndirty, we may multiply it by a potentially large factor, and I think it's possible for the multiplication to overflow in extreme cases.
• If ndirty is very small, nfreed may grow quite large before we trigger a background laundering. In the pathological case where ndirty stays equal to 0, nfreed will never be cleared.

Both of these cases are quite unlikely as you point out, but for peace of mind it seems preferable to keep the variables 64-bit.