[RFC v3] nvfs: a filesystem for persistent memory

Hi I announce a new version of NVFS - a filesystem for persistent memory. http://people.redhat.com/~mpatocka/nvfs/ git://leontynka.twibright.com/nvfs.git Changes since the last release: I reworked file read/write handling: * the functions nvfs_read and nvfs_write were deleted

Re: Expense of read_iter

On Thu, 21 Jan 2021, Matthew Wilcox wrote: > On Wed, Jan 20, 2021 at 10:12:01AM -0500, Mikulas Patocka wrote: > > Do you have some idea how to optimize the generic code that calls > > ->read_iter? > > Yes. > > > It might be better to maintain an f_iocb_flag

Re: Expense of read_iter

On Wed, 20 Jan 2021, Jan Kara wrote: > Yeah, I agree. I'm against ext4 private solution for this read problem. And > I'm also against duplicating ->read_iter functionatily in ->read handler. > The maintenance burden of this code duplication is IMHO just too big. We > rather need to improve the

Re: Expense of read_iter

On Tue, 12 Jan 2021, Zhongwei Cai wrote: > > I'm working with Mingkai on optimizations for Ext4-dax. What specific patch are you working on? Please, post it somewhere. > We think that optmizing the read-iter method cannot achieve the > same performance as the read method for Ext4-dax. > We

Re: Expense of read_iter

On Mon, 11 Jan 2021, Matthew Wilcox wrote: > On Sun, Jan 10, 2021 at 04:19:15PM -0500, Mikulas Patocka wrote: > > I put counters into vfs_read and vfs_readv. > > > > After a fresh boot of the virtual machine, the counters show "13385 4". > > After a ke

RE: [RFC v2] nvfs: a filesystem for persistent memory

On Mon, 11 Jan 2021, David Laight wrote: > From: Al Viro On Behalf Of Al Viro > > Sent: 10 January 2021 16:20 > > > > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote: > > > Hi > > > > > > I announce a new version of NVFS -

Re: [RFC v2] nvfs: a filesystem for persistent memory

On Sun, 10 Jan 2021, Al Viro wrote: > On Sun, Jan 10, 2021 at 04:14:55PM -0500, Mikulas Patocka wrote: > > > That's a good point. I split nvfs_rw_iter to separate functions > > nvfs_read_iter and nvfs_write_iter - and inlined nvfs_rw_iter_locked into > > b

Re: Expense of read_iter

On Sun, 10 Jan 2021, Matthew Wilcox wrote: > > That is the reason for that 10% degradation with read_iter. > > You seem to be focusing on your argument for "let's just permit > filesystems to implement both ->read and ->read_iter". My suggestion > is that we need to optimise the ->read_iter

Re: [RFC v2] nvfs: a filesystem for persistent memory

On Sun, 10 Jan 2021, Al Viro wrote: > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote: > > Hi > > > > I announce a new version of NVFS - a filesystem for persistent memory. > > http://people.redhat.com/~mpatocka/nvfs/ > Ut

Re: Expense of read_iter

On Thu, 7 Jan 2021, Matthew Wilcox wrote: > On Thu, Jan 07, 2021 at 08:15:41AM -0500, Mikulas Patocka wrote: > > I'd like to ask about this piece of code in __kernel_read: > > if (unlikely(!file->f_op->read_iter || file->f_op->read)) > >

[RFC v2] nvfs: a filesystem for persistent memory

Hi I announce a new version of NVFS - a filesystem for persistent memory. http://people.redhat.com/~mpatocka/nvfs/ git://leontynka.twibright.com/nvfs.git Changes since the last release: * I added a microjournal to the filesystem, it can hold up to 16 entries. Each CPU has

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Thu, 24 Sep 2020, Mikulas Patocka wrote: > On Tue, 22 Sep 2020, Matthew Wilcox wrote: > > > > There is a small window when renamed inode is neither in source nor in > > > target directory. Fsck will reclaim such inode and add it to lost+found - > > > jus

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Tue, 22 Sep 2020, Matthew Wilcox wrote: > > > The NVFS indirect block tree has a fan-out of 16, > > > > No. The top level in the inode contains 16 blocks (11 direct and 5 > > indirect). And each indirect block can have 512 pointers (4096/8). You can > > format the device with larger

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Wed, 23 Sep 2020, Dave Chinner wrote: > > > dir-test /mnt/test/linux-2.6 63000 1048576 > > > nvfs 6.6s > > > ext4 dax 8.4s > > > xfs dax 12.2s > > > > > > > > > dir-test /mnt/test/linux-2.6 63000 1048576 link > > > nvfs 4.7s > > > ext4 dax 5.6s > > >

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Wed, 23 Sep 2020, Jan Kara wrote: > On Tue 22-09-20 12:46:05, Mikulas Patocka wrote: > > > mapping 2^21 blocks requires a 5 level indirect tree. Which one if going > > > to be faster to truncate away - a single record or 2 million individual > > > blocks?

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

. > > On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote: > > On Wed, 16 Sep 2020, Mikulas Patocka wrote: > > > On Wed, 16 Sep 2020, Dan Williams wrote: > > > > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka > > > > wrote: &g

Re: NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Tue, 22 Sep 2020, Matthew Wilcox wrote: > On Mon, Sep 21, 2020 at 12:20:42PM -0400, Mikulas Patocka wrote: > > The same for directories - NVFS hashes the file name and uses radix-tree > > to locate a directory page where the directory entry is located. XFS > > b+trees

NVFS XFS metadata (was: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache)

On Wed, 16 Sep 2020, Mikulas Patocka wrote: > > > On Wed, 16 Sep 2020, Dan Williams wrote: > > > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka > > wrote: > > > > > > > My first question about nvfs is how it compares to a daxfs with >

Re: [RFC] nvfs: a filesystem for persistent memory

On Tue, 15 Sep 2020, Dan Williams wrote: > > TODO: > > > > - programs run approximately 4% slower when running from Optane-based > > persistent memory. Therefore, programs and libraries should use page cache > > and not DAX mapping. > > This needs to be based on platform firmware data f(ACPI

[PATCH] pmem: fix __copy_user_flushcache

On Wed, 16 Sep 2020, Dan Williams wrote: > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka wrote: > > > > > > > > On Wed, 16 Sep 2020, Dan Williams wrote: > > > > > On Wed, Sep 16, 2020 at 3:57 AM Mikulas Patocka > > > wrote: > &

Re: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache

On Wed, 16 Sep 2020, Dan Williams wrote: > On Wed, Sep 16, 2020 at 10:24 AM Mikulas Patocka wrote: > > > > > My first question about nvfs is how it compares to a daxfs with > > > executables and other binaries configured to use page cache with the > > > new

Re: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache

On Wed, 16 Sep 2020, Dan Williams wrote: > On Wed, Sep 16, 2020 at 3:57 AM Mikulas Patocka wrote: > > > > > > > > I'm submitting this patch that adds the required exports (so that we could > > use __copy_from_user_flushcache on x86, arm64 and powerpc). Please

[PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache

On Tue, 15 Sep 2020, Mikulas Patocka wrote: > > > On Tue, 15 Sep 2020, Mikulas Patocka wrote: > > > > > - __copy_from_user_inatomic_nocache doesn't flush cache for leading and > > > > trailing bytes. > > > > > > You

Re: [RFC] nvfs: a filesystem for persistent memory

On Tue, 15 Sep 2020, Mikulas Patocka wrote: > > > - __copy_from_user_inatomic_nocache doesn't flush cache for leading and > > > trailing bytes. > > > > You want copy_user_flushcache(). See how fs/dax.c arranges for > > dax_copy_from_it

Re: [RFC] nvfs: a filesystem for persistent memory

On Tue, 15 Sep 2020, Dan Williams wrote: > > - when the fsck.nvfs tool mmaps the device /dev/pmem0, the kernel uses > > buffer cache for the mapping. The buffer cache slows does fsck by a factor > > of 5 to 10. Could it be possible to change the kernel so that it maps DAX > > based block

Re: [RFC] nvfs: a filesystem for persistent memory

On Tue, 15 Sep 2020, Matthew Wilcox wrote: > On Tue, Sep 15, 2020 at 08:34:41AM -0400, Mikulas Patocka wrote: > > - when the fsck.nvfs tool mmaps the device /dev/pmem0, the kernel uses > > buffer cache for the mapping. The buffer cache slows does fsck by a factor > &

[RFC] nvfs: a filesystem for persistent memory

Hi I am developing a new filesystem suitable for persistent memory - nvfs. The goal is to have a small and fast filesystem that can be used on DAX-based devices. Nvfs maps the whole device into linear address space and it completely bypasses the overhead of the block layer and buffer cache.

RE: [External] regression caused by patch 6180bb446ab624b9ab8bf201ed251ca87f07b413 ("dax: fix detection of dax support for non-persistent memory block devices")

On Tue, 15 Sep 2020, Adrian Huang12 wrote: > Hi Mikulas, > > > -Original Message- > > From: Mikulas Patocka > > Sent: Monday, September 14, 2020 11:49 PM > > To: Coly Li ; Dan Williams ; Dave > > Jiang > > Cc: Jan Kara ; Vishal Verma ;

regression caused by patch 6180bb446ab624b9ab8bf201ed251ca87f07b413 ("dax: fix detection of dax support for non-persistent memory block devices")

Hi The patch 6180bb446ab624b9ab8bf201ed251ca87f07b413 ("dax: fix detection of dax support for non-persistent memory block devices") causes crash when attempting to mount the ext4 filesystem on /dev/pmem0 ("mkfs.ext4 /dev/pmem0; mount -t ext4 /dev/pmem0 /mnt/test"). The device /dev/pmem0 is

Re: [PATCH 2/2] xfs: don't update mtime on COW faults

On Wed, 9 Sep 2020, Darrick J. Wong wrote: > On Sat, Sep 05, 2020 at 01:02:33PM -0400, Mikulas Patocka wrote: > > > > > > > > I've written this program that tests it - you can integrate it into your > > testsuite. > > I don't get it. You're a filesy

[PATCH 2/2 v2] xfs: don't update mtime on COW faults

section, and these faults will incorrectly update the timestamp of the objtool binary. The updated timestamp causes make to rebuild the whole tree. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org --- fs/xfs/xfs_file.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions

Re: [PATCH 2/2] xfs: don't update mtime on COW faults

On Sat, 5 Sep 2020, Darrick J. Wong wrote: > On Sat, Sep 05, 2020 at 08:13:02AM -0400, Mikulas Patocka wrote: > > When running in a dax mode, if the user maps a page with MAP_PRIVATE and > > PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime > > whe

[PATCH 2/2] xfs: don't update mtime on COW faults

section, and these faults will incorrectly update the timestamp of the objtool binary. The updated timestamp causes make to rebuild the whole tree. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org --- fs/xfs/xfs_file.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions

[PATCH 1/2] ext2: don't update mtime on COW faults

section, and these faults will incorrectly update the timestamp of the objtool binary. The updated timestamp causes make to rebuild the whole tree. Signed-off-by: Mikulas Patocka Cc: sta...@vger.kernel.org --- fs/ext2/file.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) Index

Re: make misbehavior on ext2 in dax mode (was: a crash when running strace from persistent memory)

On Fri, 4 Sep 2020, Mikulas Patocka wrote: > Hmm, so I've found another bug in dax mode. > > If you extract the Linux kernel tree on dax-based ext2 filesystem (use the > real ext2 driver, not ext4), and then you run make twice, the second > invocation will rebuild everything

make misbehavior on ext2 in dax mode (was: a crash when running strace from persistent memory)

On Thu, 3 Sep 2020, Mikulas Patocka wrote: > Hi > > There's a bug when you run strace from dax-based filesystem. Hmm, so I've found another bug in dax mode. If you extract the Linux kernel tree on dax-based ext2 filesystem (use the real ext2 driver, not ext4), and then you run m

Re: a crash when running strace from persistent memory

On Thu, 3 Sep 2020, Linus Torvalds wrote: > On Thu, Sep 3, 2020 at 12:24 PM Mikulas Patocka wrote: > > > > There's a bug when you run strace from dax-based filesystem. > > > > -- create real or emulated persistent memory device (/dev/pmem0) > > mkfs.ext2 /de

a crash when running strace from persistent memory

Hi There's a bug when you run strace from dax-based filesystem. -- create real or emulated persistent memory device (/dev/pmem0) mkfs.ext2 /dev/pmem0 -- mount it mount -t ext2 -o dax /dev/pmem0 /mnt/test -- copy the system to it (well, you can copy just a few files that are needed for

Re: [PATCH v3] dm writecache: reject asynchronous pmem.

On Tue, 30 Jun 2020, Mikulas Patocka wrote: > > > On Tue, 30 Jun 2020, Michal Suchanek wrote: > > > The writecache driver does not handle asynchronous pmem. Reject it when > > supplied as cache. > > > > Link: https://lore.kernel.org/linux-nvdimm/87l

Re: [PATCH v3] dm writecache: reject asynchronous pmem.

er") > > Signed-off-by: Michal Suchanek Acked-by: Mikulas Patocka > --- > drivers/md/dm-writecache.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/md/dm-writecache.c b/drivers/md/dm-writecache.c > index 30505d70f423..5358894bb9fd 100644 &

Re: [PATCH v2] dm writecache: reject asynchronous pmem.

On Tue, 30 Jun 2020, Michal Suchanek wrote: > The writecache driver does not handle asynchronous pmem. Reject it when > supplied as cache. > > Link: https://lore.kernel.org/linux-nvdimm/87lfk5hahc@linux.ibm.com/ > Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") > >

Re: [PATCH] dm writecache: reject asynchronous pmem.

On Tue, 30 Jun 2020, Michal Suchanek wrote: > The writecache driver does not handle asynchronous pmem. Reject it when > supplied as cache. > > Link: https://lore.kernel.org/linux-nvdimm/87lfk5hahc@linux.ibm.com/ > Fixes: 6e84200c0a29 ("virtio-pmem: Add virtio pmem driver") > >

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

On Fri, 22 May 2020, Aneesh Kumar K.V wrote: > On 5/22/20 3:01 PM, Michal Suchánek wrote: > > On Thu, May 21, 2020 at 02:52:30PM -0400, Mikulas Patocka wrote: > > > > > > > > > On Thu, 21 May 2020, Dan Williams wrote: > > > > > &g

Re: [PATCH v2 3/5] libnvdimm/nvdimm/flush: Allow architecture to override the flush barrier

On Thu, 21 May 2020, Dan Williams wrote: > On Thu, May 21, 2020 at 10:03 AM Aneesh Kumar K.V > wrote: > > > > > Moving on to the patch itself--Aneesh, have you audited other persistent > > > memory users in the kernel? For example, drivers/md/dm-writecache.c does > > > this: > > > > > >

Re: [PATCH v2] memcpy_flushcache: use cache flusing for larger lengths

On Tue, 31 Mar 2020, Dan Williams wrote: > > The benchmark shows that 64-byte non-temporal avx512 vmovntdq is as good > > as 8, 16 or 32-bytes writes. > > ramnvdimm > > sequential write-nt 4 bytes 4.1 GB/s 1.3 GB/s > >

RE: [PATCH v2] memcpy_flushcache: use cache flusing for larger lengths

On Tue, 31 Mar 2020, Elliott, Robert (Servers) wrote: > > > > -Original Message- > > From: Mikulas Patocka > > Sent: Monday, March 30, 2020 6:32 AM > > To: Dan Williams ; Vishal Verma > > ; Dave Jiang ; Ira > > Weiny ; Mike Snitzer

[PATCH v2] memcpy_flushcache: use cache flusing for larger lengths

This is the second version of the patch - it adds a test for boot_cpu_data.x86_clflush_size. There may be CPUs with different cache line size and we don't want to run the 64-byte aligned loop on them. Mikulas From: Mikulas Patocka memcpy_flushcache: use cache flusing for larger lengths I

[PATCH] memcpy_flushcache: use cache flusing for larger lengths

ent "clflush" instruction that has very bad performance. Signed-off-by: Mikulas Patocka --- arch/x86/lib/usercopy_64.c | 36 1 file changed, 36 insertions(+) Index: linux-2.6/arch/x86/lib/

Optane nvdimm performance

Hi I performed some microbenchmarks on a system with real Optane-based nvdimm and I found out that the fastest method how to write to persistent memory is to fill a cacheline with 8 8-byte writes and then issue clwb or clflushopt on the cacheline. With this method, we can achieve 1.6 GB/s

Re: [PATCH v3 0/5] Optimize writecache when using pmem as cache

On Thu, 31 Jan 2019, Huaisheng Ye wrote: > From: Huaisheng Ye > > This patch set could be used for dm-writecache when use persistent > memory as cache data device. > > Patch 1 and 2 go towards removing unused parameter and codes which > actually doesn't really work. I agree that there is

Re: Snapshot target and DAX-capable devices

On Thu, 30 Aug 2018, Jeff Moyer wrote: > Mike Snitzer writes: > > > Until we properly add DAX support to dm-snapshot I'm afraid we really do > > need to tolerate this "regression". Since reality is the original > > support for snapshot of a DAX DM device never worked in a robust way. > >

Re: Snapshot target and DAX-capable devices

On Thu, 30 Aug 2018, Mike Snitzer wrote: > On Thu, Aug 30 2018 at 5:30am -0400, > Jan Kara wrote: > > > On Tue 28-08-18 13:56:30, Mike Snitzer wrote: > > > On Tue, Aug 28 2018 at 3:50am -0400, > > > Jan Kara wrote: > > > > > > > On Mon 27-08-18 16:43:28, Kani, Toshi wrote: > > > > > On

[PATCH] x86: optimize memcpy_flushcache

Hi Mike Could you please push this patch to the kernel 4.18-rc? Dan Williams said that he will submit it, but he forgot about it. Without this patch, dm-writecache is suffering 2% penalty because of memcpy_flushcache overhead. Mikulas From: Mikulas Patocka I use memcpy_flushcache in my

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > On Wed, May 30 2018 at 10:46P -0400, > Mikulas Patocka wrote: > > > > > > > On Wed, 30 May 2018, Mike Snitzer wrote: > > > > > > > Fine I'll deal with it. reordering the fields eliminated hol

Re: [patch 4/4] dm-writecache: use new API for flushing

On Thu, 31 May 2018, Dan Williams wrote: > On Thu, May 31, 2018 at 1:19 AM, Mikulas Patocka wrote: > > > > > > On Wed, 30 May 2018, Dan Williams wrote: > > > >> > Great find! Thanks for the due diligence. Feel free to add: &

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Dan Williams wrote: > > Great find! Thanks for the due diligence. Feel free to add: > > > > Acked-by: Dan Williams > > > > ...on the reworks to unify ARM and x86. > > One more note. The side effect of not using dax_flush() is that you > may end up flushing caches on

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > On Wed, May 30 2018 at 10:09P -0400, > Mikulas Patocka wrote: > > > And what about this? > > #define WC_MODE_PMEM(wc)((wc)->pmem_mode) > > > > The code that I had just allowed the comp

arch_wb_cache_pmem on ARM64

Hi I'd like to ask what's the purpose of dmb(osh) in the function arch_wb_cache_pmem in arch/arm64/mm/flush.c? void arch_wb_cache_pmem(void *addr, size_t size) { /* Ensure order against any prior non-cacheable writes */ dmb(osh); __clean_dcache_area_pop(addr, size); }

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > On Wed, May 30 2018 at 10:09am -0400, > Mikulas Patocka wrote: > > > > > > > On Wed, 30 May 2018, Mike Snitzer wrote: > > > > > On Wed, May 30 2018 at 9:33am -0400, > > > Mikulas Patocka wro

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > On Wed, May 30 2018 at 9:33am -0400, > Mikulas Patocka wrote: > > > > > > > On Wed, 30 May 2018, Mike Snitzer wrote: > > > > > On Wed, May 30 2018 at 9:21am -0400, > > > Mikulas Patocka wro

Re: [dm-devel] [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Jeff Moyer wrote: > Dan Williams writes: > > > When I read your patch I came away with the impression that ARM had > > not added memcpy_flushcache() yet and you were working around that > > fact. Now that I look, ARM *does* define memcpy_flushcache() and > > you're

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > On Wed, May 30 2018 at 9:21am -0400, > Mikulas Patocka wrote: > > > > > > > On Wed, 30 May 2018, Mike Snitzer wrote: > > > > > That is really great news, can you submit an incremental patch that >

Re: [patch 4/4] dm-writecache: use new API for flushing

On Wed, 30 May 2018, Mike Snitzer wrote: > That is really great news, can you submit an incremental patch that > layers ontop of the linux-dm.git 'dm-4.18' branch? > > Thanks, > Mike I've sent the current version that I have. I fixed the bugs that were reported here (missing DAX,

Re: [patch 4/4] dm-writecache: use new API for flushing

On Mon, 28 May 2018, Dan Williams wrote: > On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka wrote: > > > > > > On Sat, 26 May 2018, Dan Williams wrote: > > > >> On Sat, May 26, 2018 at 12:02 AM, Mikulas Patocka > >> wrote: > >> &

Re: [patch 4/4] dm-writecache: use new API for flushing

On Tue, 22 May 2018, Dan Williams wrote: > >> Except I'm being responsive. > > > > Except you're looking to immediately punt to linux-arm-kernel ;) > > Well, I'm not, not really. I'm saying drop ARM support, it's not ready. This is the worst thing to do - because once late cache flushing is

Re: [patch 4/4] dm-writecache: use new API for flushing

On Sat, 26 May 2018, Dan Williams wrote: > On Sat, May 26, 2018 at 12:02 AM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Fri, 25 May 2018, Dan Williams wrote: > > > >> On Fri, May 25, 2018 at 5:51 AM, Mike Snitzer <snit...@redhat.com&

Re: [patch 4/4] dm-writecache: use new API for flushing

On Fri, 25 May 2018, Dan Williams wrote: > On Fri, May 25, 2018 at 5:51 AM, Mike Snitzer <snit...@redhat.com> wrote: > > On Fri, May 25 2018 at 2:17am -0400, > > Mikulas Patocka <mpato...@redhat.com> wrote: > > > >> On Thu, 24 May 2018, Dan Willia

Re: [patch 4/4] dm-writecache: use new API for flushing

On Tue, 22 May 2018, Dan Williams wrote: > On Tue, May 22, 2018 at 11:41 AM, Mike Snitzer <snit...@redhat.com> wrote: > > On Tue, May 22 2018 at 2:39am -0400, > > Christoph Hellwig <h...@infradead.org> wrote: > > > >> On Sat, May 19, 2018 at 07:25:07A

Re: [dm-devel] [patch 4/4] dm-writecache: use new API for flushing

On Tue, 22 May 2018, Jeff Moyer wrote: > Hi, Mike, > > Mike Snitzer writes: > > > Looking at Mikulas' wrapper API that you and hch are calling into > > question: > > > > For ARM it is using arch/arm64/mm/flush.c:arch_wb_cache_pmem(). > > (And ARM does seem to be providing

Re: dm-writecache

On Fri, 18 May 2018, Dan Williams wrote: > >> ...and I wonder what the benefit is of the 16-byte case? I would > >> assume the bulk of the benefit is limited to the 4 and 8 byte copy > >> cases. > > > > dm-writecache uses 16-byte writes frequently, so it is needed for that. > > > > If we split

Re: dm-writecache

On Fri, 18 May 2018, Dan Williams wrote: > On Fri, May 18, 2018 at 8:44 AM, Mike Snitzer wrote: > > On Thu, Mar 08 2018 at 12:08pm -0500, > > Dan Williams wrote: > > > >> Mikulas sent this useful enhancement to the memcpy_flushcache API: > >> > >>

Re: [dm-devel] [PATCH] dm-writecache

On Thu, 8 Mar 2018, Christoph Hellwig wrote: > > --- /dev/null 1970-01-01 00:00:00.0 + > > +++ linux-2.6/drivers/md/dm-writecache.c2018-03-08 14:23:31.05000 > > +0100 > > @@ -0,0 +1,2417 @@ > > +#include > > missing copyright statement, or for those new-fashioned

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Thu, 9 Nov 2017, Dan Williams wrote: > On Thu, Nov 9, 2017 at 10:13 AM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Thu, 9 Nov 2017, Dan Williams wrote: > > > >> On Thu, Nov 9, 2017 at 8:37 AM, Mikulas Patocka <mpato...@redhat.com

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Thu, 9 Nov 2017, Dan Williams wrote: > On Thu, Nov 9, 2017 at 8:37 AM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Wed, 8 Nov 2017, Dan Williams wrote: > > > >> On Wed, Nov 8, 2017 at 12:26 PM, Mikulas Patocka <mpato...@redha

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Thu, 9 Nov 2017, Dan Williams wrote: > On Thu, Nov 9, 2017 at 8:40 AM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Wed, 8 Nov 2017, Dan Williams wrote: > > > >> On Wed, Nov 8, 2017 at 12:15 PM, Mikulas Patocka <mpato...@redhat.com

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Dan Williams wrote: > On Wed, Nov 8, 2017 at 12:15 PM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Wed, 8 Nov 2017, Dan Williams wrote: > > > >> On Wed, Nov 8, 2017 at 7:35 AM, Christoph Hellwig <h...@infradead.

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Dan Williams wrote: > On Wed, Nov 8, 2017 at 12:26 PM, Mikulas Patocka <mpato...@redhat.com> wrote: > > On Wed, 8 Nov 2017, Christoph Hellwig wrote: > > > >> Can you start by explaining what you actually need the vmap for? > > > &g

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Christoph Hellwig wrote: > Can you start by explaining what you actually need the vmap for? It is possible to use lvm on persistent memory. You can create linear or striped logical volumes on persistent memory and these volumes still have the direct_access method, so they

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Dan Williams wrote: > On Wed, Nov 8, 2017 at 7:35 AM, Christoph Hellwig <h...@infradead.org> wrote: > > On Wed, Nov 08, 2017 at 10:21:38AM -0500, Mikulas Patocka wrote: > >> > And what do you do for an architecture with virtuall indexed caches?

Re: [dm-devel] [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 10:21:38AM -0500, Mikulas Patocka wrote: > > > And what do you do for an architecture with virtuall indexed caches? > > > > Persistent memory is not supported on such architectures - it is only

Re: [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Christoph Hellwig wrote: > On Wed, Nov 08, 2017 at 07:33:09AM -0500, Mikulas Patocka wrote: > > We could use the function clwb() (or arch-independent wrapper dax_flush()) > > - that uses the clflushopt instruction on Broadwell or clwb on Skylake - > >

Re: [PATCH] vmalloc: introduce vmap_pfn for persistent memory

On Wed, 8 Nov 2017, Christoph Hellwig wrote: > On Tue, Nov 07, 2017 at 05:03:11PM -0500, Mikulas Patocka wrote: > > Hi > > > > I am developing a driver that uses persistent memory for caching. A > > persistent memory device can be mapped in several discontiguous

[PATCH] vmalloc: introduce vmap_pfn for persistent memory

/archives/dm-devel/2017-November/msg00026.html (see the function persistent_memory_claim) Mikulas From: Mikulas Patocka <mpato...@redhat.com> There's a function vmap that can take discontiguous pages and map them linearly to the vmalloc space. However, persistent memory may not be backed by

Re: [PATCH] dax: remove the pmem_dax_ops->flush abstraction

On Wed, 6 Sep 2017, Dan Williams wrote: > [ resend in plain text ] > > On Tue, Sep 5, 2017 at 11:29 PM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Thu, 31 Aug 2017, Dan Williams wrote: > > > >> On Thu, Aug 31, 2017 at 8:04 PM, M

Re: [PATCH] dax: remove the pmem_dax_ops->flush abstraction

On Thu, 31 Aug 2017, Dan Williams wrote: > On Thu, Aug 31, 2017 at 8:11 PM, Dan Williams <dan.j.willi...@intel.com> > wrote: > > On Thu, Aug 31, 2017 at 7:49 PM, Mikulas Patocka <mpato...@redhat.com> > > wrote: > >> > >> > >> On Thu, 3

Re: [PATCH] dax: remove the pmem_dax_ops->flush abstraction

On Thu, 31 Aug 2017, Dan Williams wrote: > On Thu, Aug 31, 2017 at 8:04 PM, Mikulas Patocka <mpato...@redhat.com> wrote: > > > > > > On Thu, 31 Aug 2017, Dan Williams wrote: > > > >> On Thu, Aug 31, 2017 at 6:47 PM, Mikulas Patocka <mpato

Re: [PATCH] dax: remove the pmem_dax_ops->flush abstraction

On Thu, 31 Aug 2017, Dan Williams wrote: > On Thu, Aug 31, 2017 at 6:47 PM, Mikulas Patocka <mpato...@redhat.com> wrote: > > The patch abebfbe2f731 ("dm: add ->flush() dax operation support") is > > buggy. A dm device may be composed of multiple underlyin

[PATCH] dax: remove the pmem_dax_ops->flush abstraction

overkill if we go through that device mapper machinery for a single flushed cache line. This patch removes the abstraction pmem_dax_ops->flush and calls arch_wb_cache_pmem() directly from dax_flush(). It also removes device mapper code that forwards the flushes. Signed-off-by: Mikulas