From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: [LSF/MM ATTEND] persistent transparent large Date: Thu, 23 Jan 2014 04:23:04 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org To: lsf-pc@lists.linux-foundation.org Return-path: Received: from mail-pa0-f42.google.com ([209.85.220.42]:53299 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751468AbaAWMXw (ORCPT ); Thu, 23 Jan 2014 07:23:52 -0500 Received: by mail-pa0-f42.google.com with SMTP id kl14so1806538pab.1 for ; Thu, 23 Jan 2014 04:23:51 -0800 (PST) Sender: linux-fsdevel-owner@vger.kernel.org List-ID: I'm eager to participate in this year's LSF/MM, but no topics of my own to propose: I need to listen to what other people are suggesting. Topics of most interest to me span mm and fs: persistent memory and xip, transparent huge pagecache, large sectors, mm scalability. Volatile ranges, memcg lowlimits, those should be on the list too. Plus I'm concerned at the way mm is now exploding: how to handle the volume. I hope most of the useful new contributors to mm can be there. Hugh From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 12:38:33 -0700 Message-ID: <20140128193833.GD20939@parisc-linux.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org To: Hugh Dickins Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote: > I'm eager to participate in this year's LSF/MM, but no topics of my > own to propose: I need to listen to what other people are suggesting. > > Topics of most interest to me span mm and fs: persistent memory and > xip, transparent huge pagecache, large sectors, mm scalability. I don't want to particularly pick on Hugh here; indeed, I know he won't take it personally which is why I've chosen to respoond to Hugh's message rather than any of the others. I'm rather annoyed at the huge disrepancy between the number of people who are *saying* they're interested in persistent memory and the number of people who are reviewing patches relating to persistent memory. As far as I'm concerned, the only people who have "earned" their way into attending the Summit based on contributing to persistent memory work would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto), Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to attend this year), Ross Zwisler (ditto), and Andreas Dilger. I'd particularly like a VM person to review these two patches: http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2 http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2 -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 12:42:08 -0800 (PST) Message-ID: References: <20140128193833.GD20939@parisc-linux.org> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org To: Matthew Wilcox Return-path: In-Reply-To: <20140128193833.GD20939@parisc-linux.org> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 28 Jan 2014, Matthew Wilcox wrote: > On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote: > > I'm eager to participate in this year's LSF/MM, but no topics of my > > own to propose: I need to listen to what other people are suggesting. > > > > Topics of most interest to me span mm and fs: persistent memory and > > xip, transparent huge pagecache, large sectors, mm scalability. > > I don't want to particularly pick on Hugh here; indeed, I know he won't > take it personally which is why I've chosen to respoond to Hugh's message Sure, your remarks are completely appropriate, and very well directed. > rather than any of the others. I'm rather annoyed at the huge disrepancy > between the number of people who are *saying* they're interested in > persistent memory and the number of people who are reviewing patches > relating to persistent memory. It's fair enough, though, for people to express an interest in a topic, without having time to contribute to it beforehand. That does not earn anyone a place, but may help the committee to choose between topics. Frustrating for you, though; and for everyone else pushing a patchset. > > As far as I'm concerned, the only people who have "earned" their way into > attending the Summit based on contributing to persistent memory work > would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto), > Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to > attend this year), Ross Zwisler (ditto), and Andreas Dilger. It might be a good idea to insist on significant review contributions in relevant areas as a condition for attendance. That's a matter for the committee to decide (I expect it's already taken into account), but it should help to improve our review rate. Counts me out, but that's okay. > > I'd particularly like a VM person to review these two patches: > > http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2 > http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2 I'd love to give you a constructive answer, but I'm not going to comment on 2 out of 22 without getting to grips with the 22. You've been thinking about this stuff for months: others need time too, and this is far from the only patchset on their queues. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 13:04:12 -0800 Message-ID: <1390943052.16253.31.camel@dabdike> References: <20140128193833.GD20939@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: Matthew Wilcox Return-path: In-Reply-To: <20140128193833.GD20939@parisc-linux.org> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2014-01-28 at 12:38 -0700, Matthew Wilcox wrote: > On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote: > > I'm eager to participate in this year's LSF/MM, but no topics of my > > own to propose: I need to listen to what other people are suggesting. > > > > Topics of most interest to me span mm and fs: persistent memory and > > xip, transparent huge pagecache, large sectors, mm scalability. > > I don't want to particularly pick on Hugh here; indeed, I know he won't > take it personally which is why I've chosen to respoond to Hugh's message > rather than any of the others. I'm rather annoyed at the huge disrepancy > between the number of people who are *saying* they're interested in > persistent memory and the number of people who are reviewing patches > relating to persistent memory. > > As far as I'm concerned, the only people who have "earned" their way into > attending the Summit based on contributing to persistent memory work > would be Dave Chinner (er ... on the ctte already), Ted Ts'o (ditto), > Jan Kara (ditto), Kirill Shutemov, Dave Hansen (who's not looking to > attend this year), Ross Zwisler (ditto), and Andreas Dilger. That rather depends on whether you think Execute In Place is the correct way to handle persistent memory, I think? I fully accept that it looks like a good place to start since it's how all embedded systems handle flash ... although looking at the proliferation of XIP hacks and filesystems certainly doesn't give one confidence that they actually got it right. Fixing XIP looks like a good thing independent of whether it's the right approach for persistent memory. However, one thing that's missing for the current patch sets is any buy in from the existing users ... can they be persuaded to drop their hacks and adopt it (possibly even losing some of the XIP specific filesystems), or will this end up as yet another XIP hack? Then there's the meta problem of is XIP the right approach. Using persistence within the current memory address space as XIP is a natural fit for mixed volatile/NV systems, but what happens when they're all NV memory? Should we be discussing some VM based handling mechanisms for persistent memory? James -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hugh Dickins Subject: Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 14:24:34 -0800 (PST) Message-ID: References: <20140128193833.GD20939@parisc-linux.org> <1390943052.16253.31.camel@dabdike> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Matthew Wilcox , Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: James Bottomley Return-path: In-Reply-To: <1390943052.16253.31.camel@dabdike> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 28 Jan 2014, James Bottomley wrote: > > Then there's the meta problem of is XIP the right approach. Using > persistence within the current memory address space as XIP is a natural > fit for mixed volatile/NV systems, but what happens when they're all NV > memory? Should we be discussing some VM based handling mechanisms for > persistent memory? Yes (but at present there's nothing on the table: is the cupboard bare?) Sorry, answer devoid of content, but since it's my thread... Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 18:52:39 -0700 Message-ID: <20140129015238.GE20939@parisc-linux.org> References: <20140128193833.GD20939@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org To: Hugh Dickins Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:44521 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755327AbaA2Bwk (ORCPT ); Tue, 28 Jan 2014 20:52:40 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, Jan 28, 2014 at 12:42:08PM -0800, Hugh Dickins wrote: > On Tue, 28 Jan 2014, Matthew Wilcox wrote: > > On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote: > > > I'm eager to participate in this year's LSF/MM, but no topics of my > > > own to propose: I need to listen to what other people are suggesting. > > > > > > Topics of most interest to me span mm and fs: persistent memory and > > > xip, transparent huge pagecache, large sectors, mm scalability. > > > > I don't want to particularly pick on Hugh here; indeed, I know he won't > > take it personally which is why I've chosen to respoond to Hugh's message > > Sure, your remarks are completely appropriate, and very well directed. Thanks. You're a long-time contributor in so many ways to the VM that I know this won't prejudice the program committee against you. > > rather than any of the others. I'm rather annoyed at the huge disrepancy > > between the number of people who are *saying* they're interested in > > persistent memory and the number of people who are reviewing patches > > relating to persistent memory. > > It's fair enough, though, for people to express an interest in a topic, > without having time to contribute to it beforehand. That does not earn > anyone a place, but may help the committee to choose between topics. Absolutely. And it might help convince the program committee to invite someone if they were seen to be active ... ;-) > > I'd particularly like a VM person to review these two patches: > > > > http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2 > > http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2 > > I'd love to give you a constructive answer, but I'm not going to > comment on 2 out of 22 without getting to grips with the 22. You've > been thinking about this stuff for months: others need time too, > and this is far from the only patchset on their queues. The first one is stand-alone. It fixes a bug that has been around for years ... but nobody noticed because nobody uses XIP. The second is a little more involved with the rest of the patchset, and I'd totally understand anyone wanting to review it in conjunction with the rest of the patchset. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large Date: Tue, 28 Jan 2014 19:39:03 -0700 Message-ID: <20140129023903.GF20939@parisc-linux.org> References: <20140128193833.GD20939@parisc-linux.org> <1390943052.16253.31.camel@dabdike> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: James Bottomley Return-path: Content-Disposition: inline In-Reply-To: <1390943052.16253.31.camel@dabdike> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Jan 28, 2014 at 01:04:12PM -0800, James Bottomley wrote: > That rather depends on whether you think Execute In Place is the correct > way to handle persistent memory, I think? I fully accept that it looks > like a good place to start since it's how all embedded systems handle > flash ... although looking at the proliferation of XIP hacks and > filesystems certainly doesn't give one confidence that they actually got > it right. One of the things I don't like about the current patch is that XIP has two completely unrelated meanings. The embedded people use it for eXecuting the kernel in-place, whereas the CONFIG_FS_XIP code is all about avoiding the page cache (for both executables and data). I'd love to rename it to prevent this confusion ... I just have no idea what to call it. Somebody suggested Map In Place (MIP). Maybe MAXIP (Map And eXecute In Place)? I'd rather something that was a TLA though. > Fixing XIP looks like a good thing independent of whether it's the right > approach for persistent memory. However, one thing that's missing for > the current patch sets is any buy in from the existing users ... can > they be persuaded to drop their hacks and adopt it (possibly even losing > some of the XIP specific filesystems), or will this end up as yet > another XIP hack? There's only one in-tree filesystem using the current interfaces (ext2) and it's converted as part of the patchset. And there're only three devices drivers implementing the current interface (dcssblk, axonram and brd). The MTD XIP is completely unrelated to this, and doesn't need to be converted. > Then there's the meta problem of is XIP the right approach. Using > persistence within the current memory address space as XIP is a natural > fit for mixed volatile/NV systems, but what happens when they're all NV > memory? Should we be discussing some VM based handling mechanisms for > persistent memory? I think this discussion would be more related to checkpointing than it is VM, so we probably wouldn't have the right people in the room for that. It would probably have been a good discussion to have at kernel summit. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [Lsf-pc] [LSF/MM ATTEND] persistent transparent large Date: Wed, 29 Jan 2014 15:00:40 -0800 Message-ID: <1391036440.2181.52.camel@dabdike.int.hansenpartnership.com> References: <20140128193833.GD20939@parisc-linux.org> <1390943052.16253.31.camel@dabdike> <20140129023903.GF20939@parisc-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Cc: Hugh Dickins , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, lsf-pc@lists.linux-foundation.org To: Matthew Wilcox Return-path: In-Reply-To: <20140129023903.GF20939@parisc-linux.org> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Tue, 2014-01-28 at 19:39 -0700, Matthew Wilcox wrote: > On Tue, Jan 28, 2014 at 01:04:12PM -0800, James Bottomley wrote: > > That rather depends on whether you think Execute In Place is the correct > > way to handle persistent memory, I think? I fully accept that it looks > > like a good place to start since it's how all embedded systems handle > > flash ... although looking at the proliferation of XIP hacks and > > filesystems certainly doesn't give one confidence that they actually got > > it right. > > One of the things I don't like about the current patch is that XIP > has two completely unrelated meanings. The embedded people use it > for eXecuting the kernel in-place, whereas the CONFIG_FS_XIP code is > all about avoiding the page cache (for both executables and data). > I'd love to rename it to prevent this confusion ... I just have no idea > what to call it. Somebody suggested Map In Place (MIP). Maybe MAXIP > (Map And eXecute In Place)? I'd rather something that was a TLA though. I understand; essentially it's about inserting existing pages into the page cache as mappings. Curiously it's not unlike one of the user space APIs the database people have requested. > > Fixing XIP looks like a good thing independent of whether it's the right > > approach for persistent memory. However, one thing that's missing for > > the current patch sets is any buy in from the existing users ... can > > they be persuaded to drop their hacks and adopt it (possibly even losing > > some of the XIP specific filesystems), or will this end up as yet > > another XIP hack? > > There's only one in-tree filesystem using the current interfaces (ext2) > and it's converted as part of the patchset. And there're only three > devices drivers implementing the current interface (dcssblk, axonram > and brd). The MTD XIP is completely unrelated to this, and doesn't need > to be converted. Quite a few of the MTD XIP patches have been *application* not kernel; those should be convertible to your patches. > > Then there's the meta problem of is XIP the right approach. Using > > persistence within the current memory address space as XIP is a natural > > fit for mixed volatile/NV systems, but what happens when they're all NV > > memory? Should we be discussing some VM based handling mechanisms for > > persistent memory? > > I think this discussion would be more related to checkpointing than it > is VM, so we probably wouldn't have the right people in the room for that. > It would probably have been a good discussion to have at kernel summit. Actually, since all the checkpointing guys are mad russians and mostly happen to work for Parallels I can see whom I can provide (I was planning to poke them with a big stick to attend, anyway). James -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by kanga.kvack.org (Postfix) with ESMTP id 9CBA86B0037 for ; Thu, 23 Jan 2014 07:23:54 -0500 (EST) Received: by mail-bk0-f42.google.com with SMTP id 6so328367bkj.1 for ; Thu, 23 Jan 2014 04:23:53 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [2607:f8b0:400e:c02::22c]) by mx.google.com with ESMTPS id kr4si10068013bkb.137.2014.01.23.04.23.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 04:23:53 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so1714666pdj.17 for ; Thu, 23 Jan 2014 04:23:51 -0800 (PST) Date: Thu, 23 Jan 2014 04:23:04 -0800 (PST) From: Hugh Dickins Subject: [LSF/MM ATTEND] persistent transparent large Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org I'm eager to participate in this year's LSF/MM, but no topics of my own to propose: I need to listen to what other people are suggesting. Topics of most interest to me span mm and fs: persistent memory and xip, transparent huge pagecache, large sectors, mm scalability. Volatile ranges, memcg lowlimits, those should be on the list too. Plus I'm concerned at the way mm is now exploding: how to handle the volume. I hope most of the useful new contributors to mm can be there. Hugh -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by kanga.kvack.org (Postfix) with ESMTP id 285456B0031 for ; Tue, 28 Jan 2014 20:52:43 -0500 (EST) Received: by mail-wg0-f41.google.com with SMTP id n12so7171929wgh.4 for ; Tue, 28 Jan 2014 17:52:42 -0800 (PST) Received: from mail.parisc-linux.org (palinux.external.hp.com. [192.25.206.14]) by mx.google.com with ESMTPS id ui5si233845wjc.22.2014.01.28.17.52.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 28 Jan 2014 17:52:41 -0800 (PST) Date: Tue, 28 Jan 2014 18:52:39 -0700 From: Matthew Wilcox Subject: Re: [LSF/MM ATTEND] persistent transparent large Message-ID: <20140129015238.GE20939@parisc-linux.org> References: <20140128193833.GD20939@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Hugh Dickins Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org On Tue, Jan 28, 2014 at 12:42:08PM -0800, Hugh Dickins wrote: > On Tue, 28 Jan 2014, Matthew Wilcox wrote: > > On Thu, Jan 23, 2014 at 04:23:04AM -0800, Hugh Dickins wrote: > > > I'm eager to participate in this year's LSF/MM, but no topics of my > > > own to propose: I need to listen to what other people are suggesting. > > > > > > Topics of most interest to me span mm and fs: persistent memory and > > > xip, transparent huge pagecache, large sectors, mm scalability. > > > > I don't want to particularly pick on Hugh here; indeed, I know he won't > > take it personally which is why I've chosen to respoond to Hugh's message > > Sure, your remarks are completely appropriate, and very well directed. Thanks. You're a long-time contributor in so many ways to the VM that I know this won't prejudice the program committee against you. > > rather than any of the others. I'm rather annoyed at the huge disrepancy > > between the number of people who are *saying* they're interested in > > persistent memory and the number of people who are reviewing patches > > relating to persistent memory. > > It's fair enough, though, for people to express an interest in a topic, > without having time to contribute to it beforehand. That does not earn > anyone a place, but may help the committee to choose between topics. Absolutely. And it might help convince the program committee to invite someone if they were seen to be active ... ;-) > > I'd particularly like a VM person to review these two patches: > > > > http://marc.info/?l=linux-fsdevel&m=138983598101510&w=2 > > http://marc.info/?l=linux-fsdevel&m=138983600001513&w=2 > > I'd love to give you a constructive answer, but I'm not going to > comment on 2 out of 22 without getting to grips with the 22. You've > been thinking about this stuff for months: others need time too, > and this is far from the only patchset on their queues. The first one is stand-alone. It fixes a bug that has been around for years ... but nobody noticed because nobody uses XIP. The second is a little more involved with the rest of the patchset, and I'd totally understand anyone wanting to review it in conjunction with the rest of the patchset. -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org