From: Mikulas Patocka <mpatocka@redhat.com> To: Jeff Moyer <jmoyer@redhat.com> Cc: Christoph Hellwig <hch@infradead.org>, device-mapper development <dm-devel@redhat.com>, Mike Snitzer <snitzer@redhat.com>, linux-nvdimm <linux-nvdimm@lists.01.org> Subject: Re: [dm-devel] [patch 4/4] dm-writecache: use new API for flushing Date: Wed, 23 May 2018 16:57:13 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.1805231639550.17160@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <x49r2m3nvyk.fsf@segfault.boston.devel.redhat.com> On Tue, 22 May 2018, Jeff Moyer wrote: > Hi, Mike, > > Mike Snitzer <snitzer@redhat.com> 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 CONFIG_ARCH_HAS_PMEM_API.) > > > > Whereas x86_64 is using memcpy_flushcache() as provided by > > CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE. > > (Yet ARM does provide arch/arm64/lib/uaccess_flushcache.c:memcpy_flushcache) > > > > Just seems this isn't purely about ARM lacking on an API level (given on > > x86_64 Mikulas isn't only using CONFIG_ARCH_HAS_PMEM_API). > > > > Seems this is more to do with x86_64 having efficient Non-temporal > > stores? > > Yeah, I think you've got that all right. > > > Anyway, I'm still trying to appreciate the details here before I can > > make any forward progress. > > Making data persistent on x64 requires 3 steps: > 1) copy the data into pmem (store instructions) > 2) flush the cache lines associated with the data (clflush, clflush_opt, clwb) > 3) wait on the flush to complete (sfence) In theory it works this way. In practice, this sequence is useless because the cache flusing instructions are horribly slow. So, the dm-writecache driver uses non-temporal stores instead of cache flushing. Now, the problem with arm64 is that it doesn't have non-temporal stores. So, memcpy_flushcache on arm64 does cached stores and flushes the cache afterwards. And this eager flushing is slower than late flushing. On arm4, you want to do cached stores, then do something else, and flush the cache as late as possible. > I'm not sure if other architectures require step 3. Mikulas' > implementation seems to imply that arm64 doesn't require the fence. I suppose that arch_wb_cache_pmem() does whatever it needs to do to flush the cache. If not, add something like arch_wb_cache_pmem_commit(). > The current pmem api provides: > > memcpy* -- step 1 > memcpy_flushcache -- this combines steps 1 and 2 > dax_flush -- step 2 > wmb* -- step 3 > > * not strictly part of the pmem api > > So, if you didn't care about performance, you could write generic code > that only used memcpy, dax_flush, and wmb (assuming other arches > actually need the wmb). What Mikulas did was to abstract out an API > that could be called by generic code that would work optimally on all > architectures. > > This looks like a worth-while addition to the PMEM API, to me. Mikulas, > what do you think about refactoring the code as Christoph suggested? I sent this patch https://www.redhat.com/archives/dm-devel/2018-May/msg00054.html so that you can take the functions pmem_memcpy, pmem_assign, pmem_flush and pmem_commit and move them to the generic linux headers. If you want to do it, do it. > Cheers, > Jeff Mikulas _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> To: Jeff Moyer <jmoyer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Cc: Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>, device-mapper development <dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, linux-nvdimm <linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org> Subject: Re: [dm-devel] [patch 4/4] dm-writecache: use new API for flushing Date: Wed, 23 May 2018 16:57:13 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.1805231639550.17160@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <x49r2m3nvyk.fsf-RRHT56Q3PSP4kTEheFKJxxDDeQx5vsVwAInAS/Ez/D0@public.gmane.org> On Tue, 22 May 2018, Jeff Moyer wrote: > Hi, Mike, > > Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 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 CONFIG_ARCH_HAS_PMEM_API.) > > > > Whereas x86_64 is using memcpy_flushcache() as provided by > > CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE. > > (Yet ARM does provide arch/arm64/lib/uaccess_flushcache.c:memcpy_flushcache) > > > > Just seems this isn't purely about ARM lacking on an API level (given on > > x86_64 Mikulas isn't only using CONFIG_ARCH_HAS_PMEM_API). > > > > Seems this is more to do with x86_64 having efficient Non-temporal > > stores? > > Yeah, I think you've got that all right. > > > Anyway, I'm still trying to appreciate the details here before I can > > make any forward progress. > > Making data persistent on x64 requires 3 steps: > 1) copy the data into pmem (store instructions) > 2) flush the cache lines associated with the data (clflush, clflush_opt, clwb) > 3) wait on the flush to complete (sfence) In theory it works this way. In practice, this sequence is useless because the cache flusing instructions are horribly slow. So, the dm-writecache driver uses non-temporal stores instead of cache flushing. Now, the problem with arm64 is that it doesn't have non-temporal stores. So, memcpy_flushcache on arm64 does cached stores and flushes the cache afterwards. And this eager flushing is slower than late flushing. On arm4, you want to do cached stores, then do something else, and flush the cache as late as possible. > I'm not sure if other architectures require step 3. Mikulas' > implementation seems to imply that arm64 doesn't require the fence. I suppose that arch_wb_cache_pmem() does whatever it needs to do to flush the cache. If not, add something like arch_wb_cache_pmem_commit(). > The current pmem api provides: > > memcpy* -- step 1 > memcpy_flushcache -- this combines steps 1 and 2 > dax_flush -- step 2 > wmb* -- step 3 > > * not strictly part of the pmem api > > So, if you didn't care about performance, you could write generic code > that only used memcpy, dax_flush, and wmb (assuming other arches > actually need the wmb). What Mikulas did was to abstract out an API > that could be called by generic code that would work optimally on all > architectures. > > This looks like a worth-while addition to the PMEM API, to me. Mikulas, > what do you think about refactoring the code as Christoph suggested? I sent this patch https://www.redhat.com/archives/dm-devel/2018-May/msg00054.html so that you can take the functions pmem_memcpy, pmem_assign, pmem_flush and pmem_commit and move them to the generic linux headers. If you want to do it, do it. > Cheers, > Jeff Mikulas
next prev parent reply other threads:[~2018-05-23 20:57 UTC|newest] Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-05-19 5:25 [patch 0/4] dm-writecache patches Mikulas Patocka 2018-05-19 5:25 ` [patch 1/4] x86: optimize memcpy_flushcache Mikulas Patocka 2018-05-19 14:21 ` Dan Williams 2018-05-24 18:20 ` [PATCH v2] " Mike Snitzer 2018-06-18 13:23 ` [PATCH v2 RESEND] " Mike Snitzer 2018-06-18 13:23 ` Mike Snitzer 2018-06-21 14:31 ` Ingo Molnar 2018-06-22 1:19 ` Mikulas Patocka 2018-06-22 1:19 ` Mikulas Patocka 2018-06-22 1:30 ` Ingo Molnar 2018-08-08 21:22 ` [PATCH v3 " Mikulas Patocka 2018-09-10 13:18 ` Ingo Molnar 2018-09-11 6:22 ` [tip:x86/asm] x86/asm: Optimize memcpy_flushcache() tip-bot for Mikulas Patocka 2018-05-19 5:25 ` [patch 2/4] swait: export the symbols __prepare_to_swait and __finish_swait Mikulas Patocka 2018-05-22 6:34 ` Christoph Hellwig 2018-05-22 18:52 ` Mike Snitzer 2018-05-23 9:21 ` Peter Zijlstra 2018-05-23 15:10 ` Mike Snitzer 2018-05-23 18:10 ` [PATCH v2] swait: export " Mike Snitzer 2018-05-23 20:38 ` Mikulas Patocka 2018-05-23 21:51 ` Mike Snitzer 2018-05-24 14:10 ` Peter Zijlstra 2018-05-24 15:09 ` Mike Snitzer 2018-05-19 5:25 ` [patch 3/4] dm-writecache Mikulas Patocka 2018-05-22 6:37 ` Christoph Hellwig 2018-05-19 5:25 ` [patch 4/4] dm-writecache: use new API for flushing Mikulas Patocka 2018-05-22 6:39 ` [dm-devel] " Christoph Hellwig 2018-05-22 6:39 ` Christoph Hellwig 2018-05-22 18:41 ` Mike Snitzer 2018-05-22 18:41 ` Mike Snitzer 2018-05-22 19:00 ` Dan Williams 2018-05-22 19:00 ` Dan Williams 2018-05-22 19:19 ` Mike Snitzer 2018-05-22 19:19 ` Mike Snitzer 2018-05-22 19:27 ` Dan Williams 2018-05-22 19:27 ` Dan Williams 2018-05-22 20:52 ` Mike Snitzer 2018-05-22 20:52 ` Mike Snitzer 2018-05-22 22:53 ` [dm-devel] " Jeff Moyer 2018-05-22 22:53 ` Jeff Moyer 2018-05-23 20:57 ` Mikulas Patocka [this message] 2018-05-23 20:57 ` Mikulas Patocka 2018-05-28 13:52 ` Mikulas Patocka 2018-05-28 13:52 ` Mikulas Patocka 2018-05-28 17:41 ` Dan Williams 2018-05-28 17:41 ` Dan Williams 2018-05-30 13:42 ` [dm-devel] " Jeff Moyer 2018-05-30 13:42 ` Jeff Moyer 2018-05-30 13:51 ` Mikulas Patocka 2018-05-30 13:51 ` Mikulas Patocka 2018-05-30 13:52 ` Jeff Moyer 2018-05-30 13:52 ` Jeff Moyer 2018-05-24 8:15 ` Mikulas Patocka 2018-05-24 8:15 ` Mikulas Patocka 2018-05-25 3:12 ` Dan Williams 2018-05-25 6:17 ` Mikulas Patocka 2018-05-25 12:51 ` Mike Snitzer 2018-05-25 12:51 ` Mike Snitzer 2018-05-25 15:57 ` Dan Williams 2018-05-25 15:57 ` Dan Williams 2018-05-26 7:02 ` Mikulas Patocka 2018-05-26 7:02 ` Mikulas Patocka 2018-05-26 15:26 ` Dan Williams 2018-05-26 15:26 ` Dan Williams 2018-05-28 13:32 ` Mikulas Patocka 2018-05-28 13:32 ` Mikulas Patocka 2018-05-28 18:14 ` Dan Williams 2018-05-28 18:14 ` Dan Williams 2018-05-30 13:07 ` Mikulas Patocka 2018-05-30 13:07 ` Mikulas Patocka 2018-05-30 13:16 ` Mike Snitzer 2018-05-30 13:16 ` Mike Snitzer 2018-05-30 13:21 ` Mikulas Patocka 2018-05-30 13:21 ` Mikulas Patocka 2018-05-30 13:26 ` Mike Snitzer 2018-05-30 13:26 ` Mike Snitzer 2018-05-30 13:33 ` Mikulas Patocka 2018-05-30 13:33 ` Mikulas Patocka 2018-05-30 13:54 ` Mike Snitzer 2018-05-30 13:54 ` Mike Snitzer 2018-05-30 14:09 ` Mikulas Patocka 2018-05-30 14:09 ` Mikulas Patocka 2018-05-30 14:21 ` Mike Snitzer 2018-05-30 14:21 ` Mike Snitzer 2018-05-30 14:46 ` Mikulas Patocka 2018-05-30 14:46 ` Mikulas Patocka 2018-05-31 3:42 ` Mike Snitzer 2018-05-31 3:42 ` Mike Snitzer 2018-06-03 15:03 ` Mikulas Patocka 2018-06-03 15:03 ` Mikulas Patocka 2018-05-31 3:39 ` Mike Snitzer 2018-05-31 3:39 ` Mike Snitzer 2018-05-31 8:16 ` Mikulas Patocka 2018-05-31 8:16 ` Mikulas Patocka 2018-05-31 12:09 ` Mike Snitzer 2018-05-31 12:09 ` Mike Snitzer 2018-05-30 15:58 ` Dan Williams 2018-05-30 15:58 ` Dan Williams 2018-05-30 22:39 ` Dan Williams 2018-05-30 22:39 ` Dan Williams 2018-05-31 8:19 ` Mikulas Patocka 2018-05-31 8:19 ` Mikulas Patocka 2018-05-31 14:51 ` Dan Williams 2018-05-31 14:51 ` Dan Williams 2018-05-31 15:31 ` Mikulas Patocka 2018-05-31 15:31 ` Mikulas Patocka 2018-05-31 16:39 ` Dan Williams 2018-05-31 16:39 ` Dan Williams
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LRH.2.02.1805231639550.17160@file01.intranet.prod.int.rdu2.redhat.com \ --to=mpatocka@redhat.com \ --cc=dm-devel@redhat.com \ --cc=hch@infradead.org \ --cc=jmoyer@redhat.com \ --cc=linux-nvdimm@lists.01.org \ --cc=snitzer@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.