[PATCH] staging/zcache: Fix/improve zcache writeback code, tie to a config option

[Konrad Rzeszutek Wilk]

On Mon, Feb 11, 2013 at 01:43:58PM -0800, Dan Magenheimer wrote:
> > From: Greg KH [mailto:gregkh at linuxfoundation.org]
> 
> > So, how about this, please draw up a specific plan for how you are going
> > to get this code out of drivers/staging/  I want to see the steps
> > involved, who is going to be doing the work, and who you are going to
> > have to get to agree with your changes to make it happen.
> >  :
> > Yeah, a plan, I know it goes against normal kernel development
> > procedures, but hey, we're in our early 20's now, it's about time we
> > started getting responsible.
> 
> Hi Greg --
> 
> I'm a big fan of planning, though a wise boss once told me:
> "Plans fail... planning succeeds".
> 
> So here's the plan I've been basically trying to pursue since about
> ten months ago, ignoring the diversion due to "zcache1 vs zcache2"
> from last summer.  There is no new functionality on this plan
> other than as necessary from feedback obtained at or prior to
> LSF/MM in April 2012.
> 
> Hope this meets your needs, and feedback welcome!
> Dan
> 
> =======
> 
> ** ZCACHE PLAN FOR PROMOTION FROM STAGING **
> 
> PLAN STEPS
> 
> 1. merge zcache and ramster to eliminate horrible code duplication
> 2. converge on a predictable, writeback-capable allocator
> 3. use debugfs instead of sysfs (per akpm feedback in 2011)
> 4. zcache side of cleancache/mm WasActive patch
> 5. zcache side of frontswap exclusive gets
> 6. zcache must be able to writeback to physical swap disk
>     (per Andrea Arcangeli feedback in 2011)
> 7. implement adequate policy for writeback
> 8. frontswap/cleancache work to allow zcache to be loaded
>     as a module
> 9. get core mm developer to review
> 10. incorporate feedback from review
> 11. get review/acks from 1-2 additional mm developers
> 12. incorporate any feedback from additional mm reviews
> 13. propose location/file-naming in mm tree
> 14. repeat 9-13 as necessary until akpm is happy and merges
> 
> STATUS/OWNERSHIP
> 
> 1. DONE as part of "new" zcache; now in staging/zcache
> 2. DONE as part of "new" zcache (cf zbud.[ch]); now in staging/zcache
>     (this was the core of the zcache1 vs zcache2 flail)
> 3. DONE as part of "new" zcache; now in staging/zcache
> 4. DONE as part of "new" zcache; per cleancache performance
>     feedback see https://lkml.org/lkml/2011/8/17/351, now
>     in staging/zcache; dependent on proposed mm patch, see
>     https://lkml.org/lkml/2012/1/25/300 
> 5. DONE as part of "new" zcache; performance tuning only,
>     now in staging/zcache; dependent on frontswap patch
>     merged in 3.7 (33c2a174)
> 6. PROTOTYPED as part of "new" zcache; protoype is now
>     in staging/zcache but has bad memory leak; reimplemented
>     to use sjennings clever tricks and proposed mm patches
>     with new version posted https://lkml.org/lkml/2013/2/6/437;
>     rejected by GregKH as it smells like new functionality
> 
>     (******** YOU ARE HERE *********)
> 
> 7. PROTOTYPED as part of "new" zcache; now in staging/zcache;
>     needs more review (plan to discuss at LSF/MM 2013)
> 8. IN PROGRESS; owned by Konrad Wilk; v2 recently posted
>    http://lkml.org/lkml/2013/2/1/542

<nods> This is the frontswap/cleancache being able to use
modularized backends.

> 9. IN PROGRESS; owned by Konrad Wilk; Mel Gorman provided
>    great feedback in August 2012 (unfortunately of "old"
>    zcache)
> 10. Konrad posted series of fixes (that now need rebasing)
>     https://lkml.org/lkml/2013/2/1/566 

<nods> That way we can run those and the frontswap in parallel.