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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7393d8c5-fb02-4087-93d1-0f999fb3cafd@default>
Date:	Mon, 11 Feb 2013 13:43:58 -0800 (PST)
From:	Dan Magenheimer <dan.magenheimer@...cle.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	sjenning@...ux.vnet.ibm.com, Konrad Wilk <konrad.wilk@...cle.com>,
	minchan@...nel.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, devel@...uxdriverproject.org, ngupta@...are.org
Subject: RE: [PATCH] staging/zcache: Fix/improve zcache writeback code, tie to
 a config option

> From: Greg KH [mailto:gregkh@...uxfoundation.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
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/