On Wed, Jan 17 2018 at 6:21pm -0500, Heinz Mauelshagen <heinzm@xxxxxxxxxx> wrote: > On 01/17/2018 10:29 PM, Mike Snitzer wrote: > > >My initial thought for dm-ram was: why? (considering we have brd and > >pmem and null_blk). But for 100 lines of code if nothing else it could > >serve as yet another example DM target for those interested in learning > >more about how to implement a DM target. Would be good to compare its > >performance with brd, null_blk and pmem though. > > With it we get the dm flexibility to set up ramdisks as opposed to > brd module parameters. It's performance is pretty similar > to brd but it's faster for larger block sizes. > Yes, the value of its simplicity for beginners is an additonal goody. > > null_blk doesn't quite fit the list lagging backing store support? Sure, but I was saying null_blk vs dm-ram. dm-ram doesn't use a backing store. > Some numbers in brd, dm-ram, null_blk order: > # fio --bs=32k --rw=randrw --numjobs=99 --group_reporting > --iodepth=12 --runtime=3 --ioengine=libaio --loops=1 --direct=1 > --exitall --name pipi --filename=/dev/ram0|egrep "read|write" > read: IOPS=334k, BW=10.2GiB/s (10.0GB/s)(30.7GiB/3009msec) > write: IOPS=334k, BW=10.2GiB/s (10.0GB/s)(30.7GiB/3009msec) > > # fio --bs=32k --rw=randrw --numjobs=99 --group_reporting > --iodepth=12 --runtime=3 --ioengine=libaio --loops=1 --direct=1 > --exitall --name pipi --filename=/dev/mapper/ram|egrep "read|write" > read: IOPS=354k, BW=10.8GiB/s (11.6GB/s)(32.4GiB/3005msec) > write: IOPS=354k, BW=10.8GiB/s (11.6GB/s)(32.5GiB/3005msec) > > # fio --bs=32k --rw=randrw --numjobs=99 --group_reporting > --iodepth=12 --runtime=3 --ioengine=libaio --loops=1 --direct=1 > --exitall --name pipi --filename=/dev/nullb0|egrep "read|write" > read: IOPS=337k, BW=10.3GiB/s (11.0GB/s)(30.9GiB/3007msec) > write: IOPS=337k, BW=10.3GiB/s (11.0GB/s)(30.9GiB/3007msec) Nice, dm-ram is doing best for that test. > >As for dm-loop, doubling the performance of the loopback driver is quite > >nice (especially with only 1/7 the number of lines of code as > >drives/block/loop.c). > > Yes, found this challenging in particular too. > Didn't bother to cover direct io or async io (yet). > Much rather wanted to keep it simple. Ah, OK. But still, doubling the buffered case isn't insignificant. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
