[dm-devel] dm-cache policy mq: promotion very picky?

[Pierre Beck]

Hi,

experimenting with dm-cache, I came across the following issue:

Having a rather large SSD available, I wanted to promote sequential I/O 
just like random I/O. Recurring sequential I/O is just as bad in a 
multi-user scenario, especially with unpromoted random I/O mixed in. So 
my dmsetup line looks like this:

# dmsetup create hybridStorage --table "0 7771064048 cache 
/dev/disk/by-id/xxx-part4 /dev/disk/by-id/yyy-part3 /dev/md/zzz 512 1 
writethrough mq 4 sequential_threshold 4294967295 random_threshold 0";

(I would appreciate a parameter to just turn random I/O detection off, btw.)

On top of "hybridStorage" an ext4 with external journal. Then, I repeat:

# echo 1 > /proc/sys/vm/drop_caches; pv smallwrite.0 > /dev/null

And watch a dstat with all relevant partitions. The 70 MB file 
"smallwrite.0" is always being read from HDD and never gets promoted. 
Only a few blocks got promoted at some point in the past.

# echo 1 > /proc/sys/vm/drop_caches; ioping -R smallwrite.0

This doesn't promote blocks, either, although it is random I/O.

# echo 1 > /proc/sys/vm/drop_caches; ioping -s 1m -R smallwrite.0

This does promote a few blocks every iteration.

# dd if=/dev/zero of=testfile bs=4096 count=100000; sync

This file was promoted halfway. Again, just piping it with pv doesn't 
promote any blocks. Piping with "cat" does promote a few blocks every 
iteration.

All in all, dm-cache policy mq seems to be very hesitant (way too 
hesitant for my taste) promoting blocks, even with sequential I/O allowed.

Maybe I'm misunderstanding how the heuristics work - what makes mq pick 
a block for promotion?

Regards,

Pierre Beck