On Fri, Sep 11, 2015 at 11:32 PM, Andrey Korolyov <andrey@xxxxxxx> wrote: >> This was running a smaller test than you with only 2G per thread. > >> Have you tried playing with the migration_threshold tunable? With >> random IO such as this we really want the cache to initially populate >> the cache but then do no churning. Could you give me the status line >> for the caches once you've run the tests please? This would tell me >> how many blocks are being demoted. > > Please CC me always, as I am not subscribed to dm-devel. > > Short-runs are tend to show better results on smq, but real-world > applications have at most long-running workloads with sustained cache > usage pattern where old algorithm shows a best result. I`ll give a try > for tunables and post results separately. Please take a look on an > attached results - at a given cache size smq outperforms all other > algorithms but both new mq and smq performs poorly when cache fills up > and issuing demotions. Status outputs are given right after test > completion. Hardware platform was changed for test, so absolute values > can differ from ones in original message. > > The r/w ratio, block size and random pattern are selected to represent > a typical SDS workload on top of the cache, but, as I pointed earlier, > it is a quite inaccurate simulation - the hit curve is impossible to > reproduce with fio. Replying to myself back - migration_threshold increase does not make situation better, when reduction results in a worse situation than with default value. As far as I can see 'new' mq suffers from the immediate processing of the promoted blocks on update when 'old' one delays their processing (not in a very good manner, though, because a large plateau of the blocks which has every right to be demoted remains in this case in front cache). -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
