From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F7B8C433E2 for ; Thu, 17 Sep 2020 06:50:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DCCF72074B for ; Thu, 17 Sep 2020 06:50:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="g5CcHwam" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726183AbgIQGup (ORCPT ); Thu, 17 Sep 2020 02:50:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44010 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726106AbgIQGup (ORCPT ); Thu, 17 Sep 2020 02:50:45 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBAF5C06174A; Wed, 16 Sep 2020 23:50:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=FT9kKWqO44LtdODqEL2MRar9ou6XSVxG66enGGgs8Es=; b=g5CcHwamwpXA0o1C6qQ9TZ56eP VOarKxr3hUyo+hJpsUhl01pWk1xTjBiFdw+lBU55OAClpb1VcZ8EEikff0FSz8RJJy1MCNTY80Rbb M8JVGM8OzPsNYvf1r6H7nZQGwtF3LORlpwgMHWiUGk4nnf9RmoNfCDEcrX6/VM2bhzCVnm23CXHLh vsbapnZKgfigwTxcdVp8K9LYMBKCcJQy5+8V5ATsTk1eQ/Hrs5II0+RfkZjMuZeKV/HTowP9yGvM+ e15KNpMXlQ2UT1mbVV93jxwsSVV8yCPQozn32YNC4AReBIWmF0f+XXjnF/IAuf1q7Y8/BrIztF/CB AETmfowA==; Received: from hch by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kInkQ-0003E4-5e; Thu, 17 Sep 2020 06:50:26 +0000 Date: Thu, 17 Sep 2020 07:50:26 +0100 From: Christoph Hellwig To: Dan Williams Cc: Mikulas Patocka , Linus Torvalds , Alexander Viro , Andrew Morton , Vishal Verma , Dave Jiang , Ira Weiny , Matthew Wilcox , Jan Kara , Eric Sandeen , Dave Chinner , "Kani, Toshi" , "Norton, Scott J" , "Tadakamadla, Rajesh (DCIG/CDI/HPS Perf)" , Linux Kernel Mailing List , linux-fsdevel , linux-nvdimm Subject: Re: [PATCH] pmem: export the symbols __copy_user_flushcache and __copy_from_user_flushcache Message-ID: <20200917065026.GA11920@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Wed, Sep 16, 2020 at 10:40:13AM -0700, Dan Williams wrote: > > Before nvfs gets included in the kernel, I need to distribute it as a > > module. So, it would make my maintenance easier. But if you don't want to > > export it now, no problem, I can just copy __copy_user_flushcache from the > > kernel to the module. > > That sounds a better plan than exporting symbols with no in-kernel consumer. Exporting symbols without a user is a complete no-go. > > > 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 per-file dax facility? > > > > nvfs is faster than dax-based filesystems on metadata-heavy operations > > because it doesn't have the overhead of the buffer cache and bios. See > > this: http://people.redhat.com/~mpatocka/nvfs/BENCHMARKS > > ...and that metadata problem is intractable upstream? Christoph poked > at bypassing the block layer for xfs metadata operations [1], I just > have not had time to carry that further. > > [1]: "xfs: use dax_direct_access for log writes", although it seems > he's dropped that branch from his xfs.git I've pushed the old branch out again: http://git.infradead.org/users/hch/xfs.git/shortlog/refs/heads/xfs-log-dax The main sticking points here are: - currently all our nvdimm/DAX code does totally pointless pmem_flush calls just to be on the safe side. That probably is one of the big speedups of nova and other academic snake oil projects over our stack. We need to handle this properly - what do we do about write error handling? That is the other big thing in the pmem/dax stack that all of the direct writers (including MAP_SYNC mmaps) pretty much ignore Once that is sorted out we can not just put the log changes like above in, but also move the buffer cache over to do a direct access and basically stop using the block layer for a pure DAX XFS.