Fix a race and a mismatch in the laundry system's shortfall mode.
The race occurs in accessing vmd->vmd_pageout_deficit. The page out worker accesses and clears this while it is calculating the shortfall. If it calculates a shortfall which vm_pageout_scan_inactive() cannot clear, vm_pageout_scan_inactive() will signal the laundry worker to enter "shortfall" mode. The laundry worker will try to use vmd->vmd_pageout_deficit in its calculation of the shortfall. However, because this variable has now been cleared (and its contents are unpredictable, as they could evidence anywhere from 0 to 10 ms of accumulation), the laundry worker's shortfall calculation is unpredictable.
The mismatch occurs in the calculation of the shortfall. r329882 added a PID controller to calculate the shortfall. When vm_pageout_scan_inactive() cannot clear the shortfall, vm_pageout_scan_inactive() will signal the laundry worker to enter "shortfall" mode. However, the laundry worker makes an independent calculation of the shortfall. Importantly, it does not consult the PID controller. This can lead to the perverse result that the laundry system cancels an in-progress background laundering operation, calculates that there is no shortfall, and does not even immediately resume background laundering.
This commit gives the laundry worker access to the shortfall calculated by the PID loop so the laundry worker will have the same shortfall information the pageout daemon has.
It is possible that vm_pageout_scan_inactive() will resolve a great deal of the shortfall. Therefore, this change may cause the laundry thread to be a touch too aggressive. However, I think the theory here is similar to the theory of using vmd->vmd_pageout_deficit: it is likely the shortfall will recur, so it is probably justified to be more aggressive in laundering pages as a one-time event.
(Note: there may be better fixes. However, I'm proposing this as a straw man.)