If a particular revivfication would drive the free pages below the limit needed for migration (or some other proof of progress), it could be dis-allowed and the read could be made from the disk. This should be uncommon since the free-list pages are not recently used.
This would certainly work, and it occurred to me too. By reserving free frames and a few I/O request blocks, migrator progress is ensured.
Another way to look at this is as a problem in hierarchical allocation. If a read I/O operation such as a migrator I/O or a real-time page read must be guaranteed to make progress, then it should allocate the necessary page frame in advance rather than doing delayed frame allocation. This has the added property that the ordinary process queueing mechanisms suffice to ensure progress.
A middle ground, which guarantees progress but defers allocation, is to use watermarking to reserve frames for real-time I/O. When a progress-critical read is queued, we check the free frame list to make sure there are enough free frames to service it. If not we run the ager. If so, we set a watermark reserving a free frame for real-time I/O allocation. When a real-time I/O operation comes up to be serviced on the disk, we allocate the frame and decrement the reserved frame count.
The idea is that there are reservations for real-time frames, and anything above that can be demand allocated. These frames cannot be revivified, but their content is still available to be copied rather than initiating a disk I/O.
On the other hand, we're talking about a complex mechanism to preserve the content of something on the order of 10 pages. Hierarchical allocation is probably simpler. Having written it down (here), I don't think it's worth it.
Jonathan