Deactivating physical pages that have been flushed from the "TLB" is an
intriguing idea but I share Jonathan's concern that the two maybe shouldn't
be linked.  Any process with a working set exceeding its PMEG size is going
to be doing excess work (though moving a page between a couple of queues
no doubt pales compared to the cost of the exception).  It may also tend
to skew paging behavior.  Even though those pages may never get freed (in
which case you gain nothing anyway) their presence on the inactive list
could alter the behavior of the page replacement scheme.  For example,
vm_pageout might see that there are "enough" pages on the inactive list
and not move more over even though many of the pages might be immediately
reclaimed, thus leaving a shortfall.  Another example would be a single
process thrashing moving lots of its pages to the front of the active list
(when they are reclaimed from the inactive list) causing all other processes
pages to pushed down and inactivated sooner.  This could be really bad
because inactivating other pages causes their physical mappings to be
removed.

I still think it is worth trying, but I'm not sure what you really want to
measure.  One thing is certainly is how often you deactivate a page that
ultimately would be deactivated anyway (without an intervening reference).
The flip side is how often you inactivated some other page that would have
remained active otherwise (and does get referenced).