[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130213184702.GD20042@phenom.dumpdata.com>
Date: Wed, 13 Feb 2013 13:47:02 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Dan Magenheimer <dan.magenheimer@...cle.com>
Cc: devel@...uxdriverproject.org, linux-kernel@...r.kernel.org,
gregkh@...uxfoundation.org, linux-mm@...ck.org, ngupta@...are.org,
sjenning@...ux.vnet.ibm.com, minchan@...nel.org
Subject: Re: [PATCH] staging: zcache: add TODO file
On Wed, Feb 13, 2013 at 10:13:06AM -0800, Dan Magenheimer wrote:
> Add zcache TODO file
>
Greg,
Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> Signed-off-by: Dan Magenheimer <dan.magenheimer@...cle.com>
> ---
> drivers/staging/zcache/TODO | 69 +++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 69 insertions(+), 0 deletions(-)
> create mode 100644 drivers/staging/zcache/TODO
>
> diff --git a/drivers/staging/zcache/TODO b/drivers/staging/zcache/TODO
> new file mode 100644
> index 0000000..c1e26d4
> --- /dev/null
> +++ b/drivers/staging/zcache/TODO
> @@ -0,0 +1,69 @@
> +
> +** ZCACHE PLAN FOR PROMOTION FROM STAGING **
> +
> +Last updated: Feb 13, 2013
> +
> +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; in staging/zcache for 3.9
> +2. DONE as part of "new" zcache (cf zbud.[ch]); in staging/zcache for 3.9
> + (this was the core of the zcache1 vs zcache2 flail)
> +3. DONE as part of "new" zcache; in staging/zcache for 3.9
> +4. DONE (w/caveats) as part of "new" zcache; per cleancache performance
> + feedback see https://lkml.org/lkml/2011/8/17/351, in
> + staging/zcache for 3.9; dependent on proposed mm patch, see
> + https://lkml.org/lkml/2012/1/25/300
> +5. DONE as part of "new" zcache; performance tuning only,
> + in staging/zcache for 3.9; dependent on frontswap patch
> + merged in 3.7 (33c2a174)
> +6. DONE (w/caveats), prototyped as part of "new" zcache, had
> + bad memory leak; reimplemented to use sjennings clever tricks
> + and proposed mm patches with new version in staging/zcache
> + for 3.9, see https://lkml.org/lkml/2013/2/6/437;
> +7. PROTOTYPED as part of "new" zcache; in staging/zcache for 3.9;
> + 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. Seth Jennings is now pursuing a separate but semi-parallel
> +track. Akpm clearly has to approve for any mm merge to happen. Minchan
> +Kim has interest but may be happy if/when zram is merged into mm. Konrad
> +Wilk may be maintainer if akpm decides compression is maintainable
> +separately from the rest of mm. (More LSF/MM 2013 discussion.)
> +
> +ZCACHE FUTURE NEW FUNCTIONALITY
> +
> +A. Support zsmalloc as an alternative high-density allocator
> + (See https://lkml.org/lkml/2013/1/23/511)
> +B. Support zero-filled pages more efficiently
> +C. Possibly support three zbuds per pageframe when space allows
> --
> 1.7.1
>
--
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/
Powered by blists - more mailing lists