Re: [PATCH 0/2] dm: add new loop and ram targets

[Mike Snitzer <snitzer@redhat.com>]

On Wed, Jan 17 2018 at  6:21pm -0500,
Heinz Mauelshagen <heinzm@redhat.com> 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