> From: Dan Magenheimer
> Sent: Wednesday, January 19, 2011 9:42 AM
> To: Andrew Morton
> Cc: [email protected]; [email protected];
> 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
> > <[email protected]> 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
>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
Hi Linus, Hi Andrew,
Hi Dan,
will this get into 2.6.39 ?
It's been running fine for me now with 2.6.37 for some time and I
have to say that it definitely cuts latencies & time needed to work
under higher memory or cpu pressure workloads (e.g. rsyncing while
compiling big programs such as libreoffice or chromium and listening
to audio at the same time) with the added bonus of less swapping and
memory consumption of the filesystem pagecache.
I haven't seen any problems so far with ext4,
btrfs very probably also will work fine in the near future (the umount
problem with btrfs I've noticed & reported is currently under
investigation & a fix on the way).
So there's no data-eating or other real problem right now that might
seriously hinder further widespread testing ;)
Getting this into mainline staging and the willingness of filesystem
developers provided - there could also be the possibility to add
support for XFS and other filesystems - making fast & excellent
filesystems (and workloads) even more efficient :)
I don't know if it's already under consideration or in linux-next but
the "zram_xvmalloc: 64K page fixes and optimizations" (which I'm
currently testing with zcache) might improve things even more.
Thanks for your consideration & Regards
Matt