From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, linux-mm@kvack.org,
ngupta@vflare.org, sjenning@linux.vnet.ibm.com,
minchan@kernel.org
Subject: Re: [PATCH] staging: zcache: add TODO file
Date: Wed, 13 Feb 2013 13:47:02 -0500 [thread overview]
Message-ID: <20130213184702.GD20042@phenom.dumpdata.com> (raw)
In-Reply-To: <1360779186-17189-1-git-send-email-dan.magenheimer@oracle.com>
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@oracle.com>
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: devel@linuxdriverproject.org, linux-kernel@vger.kernel.org,
gregkh@linuxfoundation.org, linux-mm@kvack.org,
ngupta@vflare.org, sjenning@linux.vnet.ibm.com,
minchan@kernel.org
Subject: Re: [PATCH] staging: zcache: add TODO file
Date: Wed, 13 Feb 2013 13:47:02 -0500 [thread overview]
Message-ID: <20130213184702.GD20042@phenom.dumpdata.com> (raw)
In-Reply-To: <1360779186-17189-1-git-send-email-dan.magenheimer@oracle.com>
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@oracle.com>
> Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.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
>
next prev parent reply other threads:[~2013-02-13 18:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 18:13 [PATCH] staging: zcache: add TODO file Dan Magenheimer
2013-02-13 18:13 ` Dan Magenheimer
2013-02-13 18:47 ` Konrad Rzeszutek Wilk [this message]
2013-02-13 18:47 ` Konrad Rzeszutek Wilk
2013-02-16 0:29 ` Wanpeng Li
2013-02-16 0:29 ` Wanpeng Li
2013-02-16 0:29 ` Wanpeng Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130213184702.GD20042@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=dan.magenheimer@oracle.com \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sjenning@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.