I'm -0 on changing the compaction thread priority, as opposed to using a solution like ecapriolo has suggested. This solution might even backfire and cause worse read performance if compaction loses enough priority that you end up with tons of sstables waiting to be compacted.
While 'sleeping' compaction threads manually is akin to building our own scheduler, we have so much more information than the OS scheduler does that it will probably be worthwhile. The ideal situation would be that while writes are incoming, compaction is running almost constantly, so that it is fully amortized. That is, there should only be one possible cascaded compaction at a time, and it should finish immediately before the next compaction becomes possible.