On Fri, 2017-06-09 at 13:23 -0700, Dan Williams wrote: > Allow device-mapper to route copy_from_iter operations to the > per-target implementation. In order for the device stacking to work > we > need a dax_dev and a pgoff relative to that device. This gives each > layer of the stack the information it needs to look up the operation > pointer for the next level. > > This conceptually allows for an array of mixed device drivers with > varying copy_from_iter implementations. > > Cc: Toshi Kani <[email protected]> > Reviewed-by: Mike Snitzer <[email protected]> > Signed-off-by: Dan Williams <[email protected]>
I was worried about possible overhead with additional stub calls, but it looks fine with a single thread fio write test with direct=1. 92.62% [kernel.kallsyms] [k] __copy_user_nocache 0.04% [kernel.kallsyms] [k] entry_SYSCALL_64_fastpath 0.08% libpthread-2.22.so [.] __GI___libc_write 0.01% [kernel.kallsyms] [k] sys_write 0.02% [kernel.kallsyms] [k] vfs_write 0.02% [kernel.kallsyms] [k] __vfs_write 0.02% [kernel.kallsyms] [k] ext4_file_write_iter 0.02% [kernel.kallsyms] [k] dax_iomap_rw 0.03% [kernel.kallsyms] [k] iomap_apply 0.04% [kernel.kallsyms] [k] dax_iomap_actor 0.01% [kernel.kallsyms] [k] dax_copy_from_iter 0.01% [kernel.kallsyms] [k] dm_dax_copy_from_iter 0.01% [kernel.kallsyms] [k] linear_dax_copy_from_iter 0.03% [kernel.kallsyms] [k] copy_from_iter_flushcache 0.00% [kernel.kallsyms] [k] pmem_copy_from_iter Multi-thread fio test hits hard in inode_lock(), no contention from the dm-layer. Reviewed-by: Toshi Kani <[email protected]> Thanks, -Toshi -- dm-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/dm-devel
