RE: [PATCH] staging/zcache: Fix/improve zcache writeback code, tie toa config option

From: Dan Magenheimer
Date: Mon Feb 11 2013 - 16:44:58 EST


> From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]

> 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
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
11. NOT DONE; owned by Konrad Wilk
12. TBD (depends on quantity of feedback)
13. PROPOSED; one suggestion proposed by Dan; needs
more ideas/feedback
14. TBD (depends on feedback)

WHO NEEDS TO AGREE

Not sure I can answer that. Seth seems to now be pursuing
a separate but semi-parallel track. Akpm clearly has to
approve for any mm merge to happen. Minchan has interest
but may be happy if/when zram is merged into mm. Konrad
may be maintainer if akpm decides compression is maintainable
separately from the rest of mm. (More LSF/MM 2013 discussion.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/