The check to see if a page needs to be forcibly evicted is performed within the serialization wrap-up function (and, if the page does need to be forcibly evicted, the thread additionally schedules the eviction and wakes the eviction server at the same time). The problem is the thread is holding a hazard reference: if the eviction server not only wakes up attempts to evict the page before the thread releases the hazard reference, the eviction attempt will fail, and the cycle will repeat infinitely in the tcbench program, at least on pixiebob (the problem won't occur if the eviction thread doesn't make significant progress before the thread releases its hazard reference). This is unlikely to be an interesting performance problem, but it does affect simple benchmarks where a single thread of control is inserting data as quickly as possible, especially if the inserts are in ascending or descending order.
Instead of checking for forcible eviction when a page is modified, this check when a hazard reference is being released. Further, instead of doing "size check, then schedule eviction, then wake eviction server, then release hazard reference" do "size check, schedule eviction, release hazard reference, wake eviction server"; this is required because we can't release the hazard reference before scheduling the eviction: if the hazard reference is the last one on the page, the page might be gone before we schedule the eviction.
This simplifies some things: we no longer call the routine to schedule an eviction inside a serialization function (there's no significance to that other than simplifying the world a bit).
Finally, I removed the check for general cache size checking at the same time as we were checking the individual page size. We check the general cache size every time we read a page into memory, I don't
see why that isn't going to be sufficient.