On Mon, Dec 19, 2016 at 12:08 PM, Elliott, Robert (Persistent Memory) <elliott@xxxxxxx> wrote: > > >> -----Original Message----- >> From: fio-owner@xxxxxxxxxxxxxxx [mailto:fio-owner@xxxxxxxxxxxxxxx] On >> Behalf Of Dave Jiang >> Sent: Friday, December 16, 2016 4:59 PM >> Subject: [PATCH] fio: add additional support for dev-dax ioengine >> >> Fixup options.c to add the dev-dax to ioengine list. Update fio.1 and >> HOWTO as well. Also adding example fio job file. >> > ... >> diff --git a/examples/dev-dax.fio b/examples/dev-dax.fio >> +bs=2m >> +ioengine=dev-dax > ... >> +# The dev-dax engine does IO to DAX device that are special character >> +# devices exported by the kernel (e.g. /dev/dax0.0). The device is >> +# opened normally and then the region is accessible via mmap. We do >> +# not use the O_DIRECT flag because the device is naturally direct >> +# access. The O_DIRECT flags will result in failure. The engine >> +# access the underlying NVDIMM directly once the mmapping is setup. >> +# >> +# Check the alignment requirement of your DAX device. Currently the default >> +# should be 2M. Blocksize (bs) should meet alignment requirement. > > Although /dev/dax needs the mmap() calls aligned and of a certain size, > the reads and writes within those mapped regions don't need to be. Can > these concepts be separated, with bs= continuing to just specify the > read/write size? > > Since not every write needs to persist, could you include a parameter > to use pmem_memcpy_nodrain() for the writes, plus call pmem_persist() > at a different specified rate? > I don't think we should be adding features that don't exist for the mmap engine. Unless / until the mmap engine grows support for I/O at different granularity than the mapping, or msync at different frequency than the I/O submit rate then I don't think the dev-dax engine should add these things in isolation. With the 4.10 kernel we'll start communicating the alignment of the dax-region in a reliable location so the 2M requirement can be reduced to 4K if the device-dax instance is so configured. -- To unsubscribe from this list: send the line "unsubscribe fio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
