From: Dan Magenheimer <dan.magenheimer@oracle.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: sjenning@linux.vnet.ibm.com, minchan@kernel.org,
Konrad Wilk <konrad.wilk@oracle.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
devel@linuxdriverproject.org, ngupta@vflare.org
Subject: RE: [PATCH] staging/zcache: Fix/improve zcache writeback code, tie to a config option
Date: Mon, 11 Feb 2013 14:05:01 -0800 (PST) [thread overview]
Message-ID: <334c7852-9d68-4cda-b25c-01dc5b74aaed@default> (raw)
In-Reply-To: <20130211214944.GA22090@kroah.com>
> From: Greg KH [mailto:gregkh@linuxfoundation.org]
> Subject: Re: [PATCH] staging/zcache: Fix/improve zcache writeback code, tie to a config option
>
> On Mon, Feb 11, 2013 at 01:43:58PM -0800, Dan Magenheimer wrote:
> > > From: Greg KH [mailto:gregkh@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
> > 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.)
>
> Thanks so much for this, this looks great.
>
> So, according to your plan, I shouldn't have rejected those patches,
> right? :)
>
> If so, please resend them in the next day or so, so that they can get
> into 3.9, and then you can move on to the next steps of what you need to
> do here.
>
> Sound good?
Excellent. Thanks very much. Resend coming right up!
Dan
next prev parent reply other threads:[~2013-02-11 22:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-06 18:27 [PATCH] staging/zcache: Fix/improve zcache writeback code, tie to a config option Dan Magenheimer
2013-02-06 19:09 ` Greg KH
2013-02-06 20:51 ` Dan Magenheimer
2013-02-06 21:43 ` Greg KH
2013-02-06 22:42 ` Dan Magenheimer
2013-02-07 0:03 ` Greg KH
2013-02-11 21:43 ` Dan Magenheimer
2013-02-11 21:49 ` Greg KH
2013-02-11 22:05 ` Dan Magenheimer [this message]
2013-02-13 16:55 ` Dan Magenheimer
2013-02-13 17:18 ` Greg KH
2013-02-12 19:40 ` Konrad Rzeszutek Wilk
2013-02-22 3:51 ` Ric Mason
2013-02-25 17:29 ` Dan Magenheimer
2013-02-26 0:12 ` Ric Mason
2013-02-26 20:17 ` Dan Magenheimer
2013-02-22 4:13 ` Ric Mason
2013-02-28 22:29 ` Dan Magenheimer
2013-03-01 0:35 ` Ric Mason
2013-02-11 22:07 Dan Magenheimer
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=334c7852-9d68-4cda-b25c-01dc5b74aaed@default \
--to=dan.magenheimer@oracle.com \
--cc=devel@linuxdriverproject.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.wilk@oracle.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).