From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: [dm-devel] [patch 4/4] dm-writecache: use new API for flushing Date: Wed, 30 May 2018 09:52:31 -0400 Message-ID: References: <20180519052503.325953342@debian.vm> <20180519052635.567438191@debian.vm> <20180522063946.GB8054@infradead.org> <20180522184103.GA25826@redhat.com> <20180522191942.GB25904@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: (Jeff Moyer's message of "Wed, 30 May 2018 09:42:40 -0400") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: Dan Williams Cc: Christoph Hellwig , device-mapper development , Mikulas Patocka , Mike Snitzer , linux-nvdimm List-Id: dm-devel.ids Jeff Moyer writes: > 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 avoiding it. You use memcpy+arch_wb_pmem where arch_wb_pmem on >> ARM64 is defined as __clean_dcache_area_pop(dst, cnt). The ARM >> memcpy_flushcache() implementation is: >> >> memcpy(dst, src, cnt); >> __clean_dcache_area_pop(dst, cnt); >> >> So, I do not see how what you're doing is any less work unless you are >> flushing less than you copy? >> >> If memcpy_flushcache() is slower than memcpy + arch_wb_pmem then the >> ARM implementation is broken and that needs to be addressed not worked >> around in a driver. > > I think Mikulas wanted to batch up multiple copies and flush at the > end. According to his commit message, that batching gained him 2% > performance. Nevermind me, I just caught up with the rest of the thread. :) -Jeff