Userspace and Kernel space policies.

To a limited extent this can be implement in user space. At a most basic level, if we are using a multicore system and a single core can easily saturate the SSD then the installer suggesting compression seems a safe bet (e.g. on my Core2Duo can compress lzo compresses at 44MB/s while a typical USB stick can only write at 10MB/s). It seems that somewhat more dynamic polices could also be implemented in userspace, e.g. using remount,compress.

On obvious policy is, only compress using idle cycles. This would mean that a standard IO bound task writing compressible data should run faster while not affecting the performance of CPU bound tasks (assuming decompression time is negligible). In some cases it should also give better write performance than either compress or no_compress E.g. when the CPU can compress at 30MB/s and the media can write at 30MB/s, then we could write 30MB/s of data compressed down to (say) 17MB/s and 13MB/s of uncompressed data, for a total of 43MB/s.

If the user manually selects such a policy they can't blame the kernel devs if it is not suitable :). Whether that complexity is worthwhile is another issue.