From: Dave Chinner <david@fromorbit.com> To: Zhongwei Cai <sunrise_l@sjtu.edu.cn> Cc: Mikulas Patocka <mpatocka@redhat.com>, Theodore Ts'o <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>, David Laight <David.Laight@aculab.com>, Mingkai Dong <mingkaidong@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>, Steven Whitehouse <swhiteho@redhat.com>, Eric Sandeen <esandeen@redhat.com>, Dave Chinner <dchinner@redhat.com>, Wang Jianchao <jianchao.wan9@gmail.com>, Rajesh Tadakamadla <rajesh.tadakamadla@hpe.com>, linux-kernel <linux-kernel@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-nvdimm <linux-nvdimm@lists.01.org> Subject: Re: Expense of read_iter Date: Wed, 20 Jan 2021 15:47:00 +1100 [thread overview] Message-ID: <20210120044700.GA4626@dread.disaster.area> (raw) In-Reply-To: <1224425872.715547.1610703643424.JavaMail.zimbra@sjtu.edu.cn> On Fri, Jan 15, 2021 at 05:40:43PM +0800, Zhongwei Cai wrote: > On Thu, 14 Jan 2021, Mikulas wrote: > For Ext4-dax, the overhead of dax_iomap_rw is significant > compared to the overhead of struct iov_iter. Although methods > proposed by Mikulas can eliminate the overhead of iov_iter > well, they can not be applied in Ext4-dax unless we implement an > internal "read" method in Ext4-dax. > > For Ext4-dax, there could be two approaches to optimizing: > 1) implementing the internal "read" method without the complexity > of iterators and dax_iomap_rw; Please do not go an re-invent the wheel just for ext4. If there's a problem in a shared path - ext2, FUSE and XFS all use dax_iomap_rw() as well, so any improvements to that path benefit all DAX users, not just ext4. > 2) optimizing how dax_iomap_rw works. > Since dax_iomap_rw requires ext4_iomap_begin, which further involves > the iomap structure and others (e.g., journaling status locks in Ext4), > we think implementing the internal "read" method would be easier. Maybe it is, but it's also very selfish. The DAX iomap path was written to be correct for all users, not inecessarily provide optimal performance. There will be lots of things that could be done to optimise it, so rather than creating a special snowflake in ext4 that makes DAX in ext4 much harder to maintain for non-ext4 DAX developers, please work to improve the common DAX IO path and so provide the same benefit to all the filesystems that use it. Cheers, Dave. -- Dave Chinner david@fromorbit.com _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org
WARNING: multiple messages have this Message-ID (diff)
From: Dave Chinner <david@fromorbit.com> To: Zhongwei Cai <sunrise_l@sjtu.edu.cn> Cc: Mikulas Patocka <mpatocka@redhat.com>, Theodore Ts'o <tytso@mit.edu>, Matthew Wilcox <willy@infradead.org>, David Laight <David.Laight@aculab.com>, Mingkai Dong <mingkaidong@gmail.com>, Andrew Morton <akpm@linux-foundation.org>, Jan Kara <jack@suse.cz>, Steven Whitehouse <swhiteho@redhat.com>, Eric Sandeen <esandeen@redhat.com>, Dave Chinner <dchinner@redhat.com>, Wang Jianchao <jianchao.wan9@gmail.com>, Rajesh Tadakamadla <rajesh.tadakamadla@hpe.com>, linux-kernel <linux-kernel@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-nvdimm <linux-nvdimm@lists.01.org> Subject: Re: Expense of read_iter Date: Wed, 20 Jan 2021 15:47:00 +1100 [thread overview] Message-ID: <20210120044700.GA4626@dread.disaster.area> (raw) In-Reply-To: <1224425872.715547.1610703643424.JavaMail.zimbra@sjtu.edu.cn> On Fri, Jan 15, 2021 at 05:40:43PM +0800, Zhongwei Cai wrote: > On Thu, 14 Jan 2021, Mikulas wrote: > For Ext4-dax, the overhead of dax_iomap_rw is significant > compared to the overhead of struct iov_iter. Although methods > proposed by Mikulas can eliminate the overhead of iov_iter > well, they can not be applied in Ext4-dax unless we implement an > internal "read" method in Ext4-dax. > > For Ext4-dax, there could be two approaches to optimizing: > 1) implementing the internal "read" method without the complexity > of iterators and dax_iomap_rw; Please do not go an re-invent the wheel just for ext4. If there's a problem in a shared path - ext2, FUSE and XFS all use dax_iomap_rw() as well, so any improvements to that path benefit all DAX users, not just ext4. > 2) optimizing how dax_iomap_rw works. > Since dax_iomap_rw requires ext4_iomap_begin, which further involves > the iomap structure and others (e.g., journaling status locks in Ext4), > we think implementing the internal "read" method would be easier. Maybe it is, but it's also very selfish. The DAX iomap path was written to be correct for all users, not inecessarily provide optimal performance. There will be lots of things that could be done to optimise it, so rather than creating a special snowflake in ext4 that makes DAX in ext4 much harder to maintain for non-ext4 DAX developers, please work to improve the common DAX IO path and so provide the same benefit to all the filesystems that use it. Cheers, Dave. -- Dave Chinner david@fromorbit.com
next prev parent reply other threads:[~2021-01-20 4:47 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-07 13:15 [RFC v2] nvfs: a filesystem for persistent memory Mikulas Patocka 2021-01-07 13:15 ` Mikulas Patocka 2021-01-07 15:11 ` Expense of read_iter Matthew Wilcox 2021-01-07 15:11 ` Matthew Wilcox 2021-01-07 16:43 ` Mingkai Dong 2021-01-07 16:43 ` Mingkai Dong 2021-01-12 13:45 ` Zhongwei Cai 2021-01-12 14:06 ` David Laight 2021-01-12 14:06 ` David Laight 2021-01-13 16:44 ` Mikulas Patocka 2021-01-13 16:44 ` Mikulas Patocka 2021-01-15 9:40 ` Zhongwei Cai 2021-01-20 4:47 ` Dave Chinner [this message] 2021-01-20 4:47 ` Dave Chinner 2021-01-20 14:18 ` Jan Kara 2021-01-20 14:18 ` Jan Kara 2021-01-20 15:12 ` Mikulas Patocka 2021-01-20 15:12 ` Mikulas Patocka 2021-01-20 15:44 ` David Laight 2021-01-20 15:44 ` David Laight 2021-01-21 15:47 ` Matthew Wilcox 2021-01-21 15:47 ` Matthew Wilcox 2021-01-21 16:06 ` Mikulas Patocka 2021-01-21 16:06 ` Mikulas Patocka 2021-01-21 16:30 ` Zhongwei Cai 2021-01-07 18:59 ` Mikulas Patocka 2021-01-07 18:59 ` Mikulas Patocka 2021-01-10 6:13 ` Matthew Wilcox 2021-01-10 6:13 ` Matthew Wilcox 2021-01-10 21:19 ` Mikulas Patocka 2021-01-10 21:19 ` Mikulas Patocka 2021-01-11 0:18 ` Matthew Wilcox 2021-01-11 0:18 ` Matthew Wilcox 2021-01-11 21:10 ` Mikulas Patocka 2021-01-11 21:10 ` Mikulas Patocka 2021-01-11 10:11 ` David Laight 2021-01-11 10:11 ` David Laight 2021-01-10 16:20 ` [RFC v2] nvfs: a filesystem for persistent memory Al Viro 2021-01-10 16:20 ` Al Viro 2021-01-10 16:51 ` Al Viro 2021-01-10 16:51 ` Al Viro 2021-01-10 21:14 ` Mikulas Patocka 2021-01-10 21:14 ` Mikulas Patocka 2021-01-10 23:40 ` Al Viro 2021-01-10 23:40 ` Al Viro 2021-01-11 11:41 ` Mikulas Patocka 2021-01-11 11:41 ` Mikulas Patocka 2021-01-11 10:29 ` David Laight 2021-01-11 10:29 ` David Laight 2021-01-11 11:44 ` Mikulas Patocka 2021-01-11 11:44 ` Mikulas Patocka 2021-01-11 11:57 ` David Laight 2021-01-11 11:57 ` David Laight 2021-01-11 14:43 ` Al Viro 2021-01-11 14:43 ` Al Viro 2021-01-11 14:54 ` David Laight 2021-01-11 14:54 ` David Laight
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=20210120044700.GA4626@dread.disaster.area \ --to=david@fromorbit.com \ --cc=David.Laight@aculab.com \ --cc=akpm@linux-foundation.org \ --cc=dchinner@redhat.com \ --cc=esandeen@redhat.com \ --cc=jack@suse.cz \ --cc=jianchao.wan9@gmail.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@lists.01.org \ --cc=mingkaidong@gmail.com \ --cc=mpatocka@redhat.com \ --cc=rajesh.tadakamadla@hpe.com \ --cc=sunrise_l@sjtu.edu.cn \ --cc=swhiteho@redhat.com \ --cc=tytso@mit.edu \ --cc=willy@infradead.org \ /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.