Messages in this thread | | | Date | Thu, 17 Feb 2011 12:14:49 -0800 (PST) | From | Dan Magenheimer <> | Subject | PING? cleancache for 2.6.39 window? |
| |
> From: Dan Magenheimer > Sent: Wednesday, January 19, 2011 9:42 AM > To: Andrew Morton > Cc: torvalds@linux-foundation.org; linux-kernel@vger.kernel.org; > Christoph Hellwig; Jeremy Fitzhardinge > Subject: RE: Ping? RE: [GIT PULL] mm/vfs/fs:cleancache for 2.6.37 merge > window > > > On Wed, 27 Oct 2010 11:37:47 -0700 (PDT) Dan Magenheimer > > <dan.magenheimer@oracle.com> wrote: > > > > > Ping? I hope you are still considering this. If not or if > > > there are any questions I can answer, please let me know. > > > > What's happened here is that the patchset has gone through its > > iterations and a few people have commented and then after a while, > > nobody had anything to say about the code so nobody said anything > more. > > > > But silence doesn't mean acceptance - it just means that nobody had > > anything to say. > > > > I think I looked at the earlier iterations, tried to understand the > > point behind it all, made a few code suggestions and eventually tuned > > out. At that time (and hence at this time) I just cannot explain to > > myself why we would want to merge this code. > > > > All new code is a cost/benefit decision. The costs are pretty well > > known: larger codebase, more code for us and our "customers" to > > maintain and support, etc. That the code pokes around in vfs and > > various filesystems does increase those costs a little. > > > > But the extent of the benefits to our users aren't obvious to me. > The > > coe is still xen-specific, I believe? If so, that immediately > reduces > > the benefit side by a large amount simply because of the reduced > > audience. > > > > We did spend some time trying to get this wired up to zram so that > the > > feature would be potentially useful to *all* users, thereby setting > the > > usefulness multiplier back to 1.0. But I don't recall that anything > > came of this? > > > > I also don't know how useful the code is to its intended > > micro-audience: xen users! > > > > So can we please revisit all this from the top level? Jeremy, your > > input would be valuable. Christoph, I recall that you had technical > > objections - can you please repeat those? > > > > It's the best I can do to kick this along, sorry. > > Hi Andrew (and Linus) -- > > Time to re-open this conversation (for 2.6.39 merge window)? > > Assuming GregKH approves kztmem as a staging driver, it should > now set "the usefulness multiplier back to 1.0". Kztmem > is a superset of Nitin's zcache and zram but more dynamic > and is completely independent of Xen and virtualization. > > See kztmem overview: https://lkml.org/lkml/2011/1/18/170 > > And I believe Christoph's technical objections have all been > resolved. See longer version of previous reply here: > https://lkml.org/lkml/2010/10/30/226 > > So please reconsider cleancache!
Hi Andrew (and Linus) --
As you may have seen, gregkh has taken zcache into drivers/staging for merging when the 2.6.39 window opens. And zcache (which works entirely in-kernel, no virtualization required) depends on cleancache.
Cleancache and zcache are both in linux-next and, via linux-next, in mmotm. Last October, Linus said that he preferred cleancache to merge via you (Andrew), not pulled from my git tree. So:
1) Is cleancache finally now acceptable for merging in the upcoming 2.6.39 window? and 2) If so, is there anything else I need to do to ensure the merging of cleancache happens during the open window or will it all happen automagically (from my point of view) through your (Andrew's) normal open-window processes?
Sorry to be excessively persistent, but I don't want to miss the 2.6.39 window due to my newbie-ness. And I plan to be on vacation for some time during March and would also like to ensure I don't miss something *I* need to do before or during the window.
Thanks, Dan Magenheimer
| |