On Tue, Jul 12 2016 at 6:22pm -0400,
Kani, Toshimitsu <toshi.kani(a)hpe.com> wrote:
On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote:
> BTW, if in your testing you could evaluate/quantify any extra overhead
> from DM that'd be useful to share. It could be there are bottlenecks
> that need to be fixed, etc.
Here are some results from fio benchmark. The test is single-threaded and is
bound to one CPU.
DAX LVM IOPS NOTE
Y N 790K
Y Y 754K 5% overhead with LVM
N N 567K
N Y 457K 20% overhead with LVM
DAX: Y: mount -o dax,noatime, N: mount -o noatime
LVM: Y: dm-linear on pmem0 device, N: pmem0 device
fio: bs=4k, size=2G, direct=1, rw=randread, numjobs=1
Among the 5% overhead with DAX/LVM, the new DM direct_access interfaces
account for less than 0.5%.
The average latency increases slightly from 0.93us to 0.95us. I think most of
the overhead comes from the submit_bio() path, which is used only for
accessing metadata with DAX. I believe this is due to cloning bio for each
request in DM. There is 12% more L2 miss in total.
Without DAX, 20% overhead is observed with LVM. Average latency increases
from 1.39us to 1.82us. Without DAX, bio is cloned for both data and metadata.
Thanks for putting this summary together. Unfortunately none of the DM
changes can be queued for 4.8 until Jens takes the 2 block core patches:
Not sure what the hold up and/or issue is with them. But I've asked
twice (and implicilty a 3rd time here). Hopefully they land in time for