Re: [PATCH v9 00/16] re-enable DAX PMD support
On Tue, Nov 01, 2016 at 01:54:02PM -0600, Ross Zwisler wrote: > DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based > locking. This series allows DAX PMDs to participate in the DAX radix tree > based locking scheme so that they can be re-enabled. I've seen patch 0/16 - where did you send the other 16? I need to pick up the bug fix that is in this patch set... > Previously we had talked about this series going through the XFS tree, but > Jan has a patch set that will need to build on this series and it heavily > modifies the MM code. I think he would prefer that series to go through > Andrew Morton's -MM tree, so it probably makes sense for this series to go > through that same tree. Seriously, I was 10 minutes away from pushing out the previous version of this patchset as a stable topic branch, just like has been discussed and several times over the past week. Indeed, I mentioned that I was planning on pushing out this topic branch today not more than 4 hours ago, and you were on the cc list. The -mm tree is not the place to merge patchsets with dependencies like this because it's an unstable, rebasing tree. Hence it cannot be shared and used as the base of common development between multiple git trees like we have for the fs/ subsystem. This needs to go out as a stable topic branch so that other dependent work can reliably build on top of it for the next merge window. e.g. the ext4 DAX iomap patch series that is likely to be merged through the ext4 tree, so it needs a stable branch. There's iomap direct IO patches for XFS pending, and they conflict with this patchset. i.e. we need a stable git base to work from... Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 0/11] ext4: Convert ext4 DAX IO to iomap framework
On Wed, Nov 02, 2016 at 09:03:53AM -0400, Theodore Ts'o wrote: > On Wed, Nov 02, 2016 at 12:09:03AM +0100, Jan Kara wrote: > > > > I plan to grab Ross's PMD series in the next couple of days and I'll > > > > push it out as a stable topic branch once I've sanity tested it. I > > > > don't really want to take a big chunk of ext4 stuff through the XFS > > > > tree if it can be avoided > > > > > > Yea, we also need to figure out how to get Jan's "dax: Clear dirty bits > > > after > > > flushing caches" set merged, which is mostly MM stuff and I think will go > > > through akpm's tree? That set is also based on my PMD stuff. > > > > Yeah, I've spoken to Andrew and he wants to take the MM changes through his > > tree. I'll talk to him how to make this happen given the patches the series > > depends on but the series still needs some review so "how to merge" is not > > exactly a question of the day... > > I assume there isn't a convenient git tree I can pull for the purposes > of testing Jan's patch series and for the purposes of seeing how > everything fits together? I think Jan posted a test branch with all the current stuff under review in it here: git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git dax > In other words, as far as I understand > things there currently isn't an unstable topic branch I can pull for > the purposes of review and testing, but hopefully Dave will make a > stable topic branch in a few days. Is that right? I've got the dax-pmd topic branch running regression tests right now. I'm hoping that all goes well and if it does I'll get it out by the end of the day. Cheers, Dave. -- Dave Chinner da...@fromorbit.com ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
回复：如何做好.企.业.采.购，降.低.运.营.成.本
From: 崔曝 / xvqlwr...@zpywil.net To: linux-nvdimm@lists.01.org Sent: 2016-11-3/1:51:34 自信的生命最美丽！ ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 11/11] dax: Rip out get_block based IO support
On Tue, Nov 01, 2016 at 10:06:21PM +0100, Jan Kara wrote: > No one uses functions using the get_block callback anymore. Rip them > out. Documentation/filesystems/dax.txt will also need some updates for this. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 08/11] ext4: Convert DAX faults to iomap infrastructure
On Tue, Nov 01, 2016 at 10:06:18PM +0100, Jan Kara wrote: > Convert DAX faults to use iomap infrastructure. We would not have to start > transaction in ext4_dax_fault() anymore since ext4_iomap_begin takes > care of that but so far we do that to avoid lock inversion of > transaction start with DAX entry lock which gets acquired in > dax_iomap_fault() before calling ->iomap_begin handler. So far I've tried to avoid the need to avoid having multiple iomap_ops for the same fs. Would you be fine with a new IOMAP_FAULT flag for write faults? ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 02/11] ext4: Allow unaligned unlocked DAX IO
On Tue, Nov 01, 2016 at 10:06:12PM +0100, Jan Kara wrote: > Currently we don't allow unaligned writes without inode_lock. This is > because zeroing of partial blocks could cause data corruption for racing > unaligned writes to the same block. However DAX handles zeroing during > block allocation and thus zeroing of partial blocks cannot race. Allow > DAX unaligned IO to run without inode_lock. DAX writes should always take the inode lock. Without that you break the expectations of existing applications that did not specify O_DIRECT. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 0/11] ext4: Convert ext4 DAX IO to iomap framework
On Wed, Nov 02, 2016 at 12:09:03AM +0100, Jan Kara wrote: > > > I plan to grab Ross's PMD series in the next couple of days and I'll > > > push it out as a stable topic branch once I've sanity tested it. I > > > don't really want to take a big chunk of ext4 stuff through the XFS > > > tree if it can be avoided > > > > Yea, we also need to figure out how to get Jan's "dax: Clear dirty bits > > after > > flushing caches" set merged, which is mostly MM stuff and I think will go > > through akpm's tree? That set is also based on my PMD stuff. > > Yeah, I've spoken to Andrew and he wants to take the MM changes through his > tree. I'll talk to him how to make this happen given the patches the series > depends on but the series still needs some review so "how to merge" is not > exactly a question of the day... I assume there isn't a convenient git tree I can pull for the purposes of testing Jan's patch series and for the purposes of seeing how everything fits together? In other words, as far as I understand things there currently isn't an unstable topic branch I can pull for the purposes of review and testing, but hopefully Dave will make a stable topic branch in a few days. Is that right? - Ted ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH v2 34/37] docs: fix locations of several documents that got moved
On 11/02/2016 05:31 AM, Pavel Machek wrote: > Hi! > >>> Dunno, but kernel-parameters.txt was already quite long... for a file >>> that is referenced quite often. Adding admin-guide/ into the path does >>> not really help. >> >> The big string name starts with Documentation/ :) There are some discussions >> about changing it to doc/ (or docs/). Also, as you said, kernel-parameters >> is already a big name. Perhaps we could use, instead, >>> "kernel-parms". > > cmdline? You would not believe the number of users I've dealt with that have confused "cmdline/command line" (aka prompt) with "kernel parameter". I go back and edit customer debug requests to make sure there's no use of cmdline in place of kernel parameter. For the love of every customer facing engineer out there, please stop using cmdline ;). P. > >> If we rename kernel-parameters.rst to kernel-parms.rst, plus the doc/ rename, >> then the string size will actually reduce: >> >> -(see Documentation/kernel-parameters.txt), the minimum possible >> +(see doc/admin-guide/kernel-parms.rst), the minimum possible >> >>> Maybe admin-guide should go directly into Documentation/ , as that's >>> what our users are interested in? >> >> There are several problems if we keep them at Documentation/ dir: >> >> - We'll end by mixing documents already converted to ReST with documents >> not converted yet; >> >> - A rename is needed anyway, as Sphinx only accepts ReST files that end >> with the extension(s) defined at Documentation/conf.py (currently, >> .rst); >> >> - A partial documentation build is made by sub-directory. If we put >> files under /Documentation, there's no way to build just one >> book. > > Well, documentation is primarily for users. I'm sure tools can adapt... > >>> Plus, I'm not sure how many developers will figure out that process/ >>> is what describes kernel patch submission process. We have processes >>> in the kernel, after all... >> >> Do you have a better idea? > > development/ ? > > Best regards, > Pavel > ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 01/21] mm: Join struct fault_env and vm_fault
On Tue, Nov 01, 2016 at 11:36:08PM +0100, Jan Kara wrote: > Currently we have two different structures for passing fault information > around - struct vm_fault and struct fault_env. DAX will need more > information in struct vm_fault to handle its faults so the content of > that structure would become event closer to fault_env. Furthermore it > would need to generate struct fault_env to be able to call some of the > generic functions. So at this point I don't think there's much use in > keeping these two structures separate. Just embed into struct vm_fault > all that is needed to use it for both purposes. What about just reference fault_env from vm_fault? We don't always need vm_fault where we nee fault_env. It may save space on stack for some codepaths. -- Kirill A. Shutemov ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 0/21 v4] dax: Clear dirty bits after flushing caches
On Wed, Nov 02, 2016 at 12:13:18AM +0100, Jan Kara wrote: > Hi, > > forgot to add Kirill to CC since this modifies the fault path he changed > recently. I don't want to resend the whole series just because of this so > at least I'm pinging him like this... I see strange mix x/20 and x/21 patches. Which should I look at? -- Kirill A. Shutemov ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
