Have you also considered disabling the HK in your tempdb caches?
For large volumes of short-lived 'active' pages (in the tempdb cache), disabling the HK can often times provide large reductions in physical writes for tempdb devices since the writes are deferred until the 'dirty' pages hit the wash marker. When the 'dirty' pages hit the wash marker, if said pages are no longer in use (ie, pages are unpinned), then the page is not flushed to disk but rather has a bit flipped to indicate the page is now 'clean'.
Granted, a lot (though not all) of tempdb writes (to disk) are now handled asynchronously so many user processes won't notice any performance improvement from a reduction in tempdb device writes, but removal of large quantities of unnecessary tempdb device writes may reduce the load on the disk subsystem thus providing a benefit for other disk operations, ymmv.
I've worked at several clients where 50-80% of all disk writes were a result of the HK flushing pages to tempdb devices. In most case disabling the HK allowed us to eliminate the vast majority of the tempdb writes.
Keep in mind that disabling the HK does take some research and planning, eg:
- verify the current volume of writes is due to HK activity and not due to a tempdb cache that is too small; if you have any appreciable volume of physical *reads* from your tempdb devices then your tempdb cache is likely too small (eg, pages are flushed from cache to disk, just to be re-read from disk later when needed); if you have a largish volume of tempdb device physical *reads* then you may need to increase the size of the cache and/or pool
- make sure the wash size is large enough to allow for any page writes to complete without incurring a stall on the cache; hopefully the vast majority of dirty pages crossing the wash marker are also unpinned, but in the case of having valid pages to flush to disk you want to make sure the writes have plenty of time to complete before causing a stall in the cache; obviously (?) it helps if your tempdb device IO service times are relatively fast