PING? cleancache for 2.6.39 window?

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> 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