Message-ID: <20120326155018.GA6163@phenom.dumpdata.com>
Date:	Mon, 26 Mar 2012 11:50:19 -0400
From:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Seth Jennings <sjenning@...ux.vnet.ibm.com>,
	devel@...verdev.osuosl.org,
	Dan Magenheimer <dan.magenheimer@...cle.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Robert Jennings <rcj@...ux.vnet.ibm.com>,
	Nitin Gupta <ngupta@...are.org>
Subject: Re: [PATCH] staging: zsmalloc: add user-definable alloc/free funcs

On Mon, Mar 19, 2012 at 04:34:09PM -0700, Greg Kroah-Hartman wrote:
> On Mon, Mar 19, 2012 at 01:54:56PM -0500, Seth Jennings wrote:
> > > I'm sorry, I know this isn't fair for your specific patch, but we have
> > > to stop this sometime, and as this patch adds code isn't even used by
> > > anyone, its a good of a time as any.
> > 
> > So, this the my first "promotion from staging" rodeo.  I would love to
> > see this code mainlined ASAP.  How would I/we go about doing that?
> 
> What subsystem should this code live in?  The -mm code, I'm guessing,
> right?  If so, submit it to the linux-mm mailing list for inclusion, you
> can point them at what is in drivers/staging right now, or probably it's
> easier if you just make a new patch that adds the code that is in
> drivers/staging/ to the correct location in the kernel.  That way it's
> easier to review and change.  When it finally gets accepted, we can then
> delete the drivers/staging code.


Hey Greg,

Little background - for zcache to kick-butts (both Dan and Seth posted some
pretty awesome benchmark numbers) it depends on the frontswap - which is in
the #linux-next. Dan made an attempt to post it for a GIT PULL and an interesting
conversation ensued where folks decided it needs more additions before they were
comfortable with it. zcache isn't using those additions, but I don't see why
it couldn't use them.

The things that bouncing around in my head are:
 - get a punch-out list (ie todo) of what MM needs for the zcache to get out.
   I think posting it as a new driver would be right way to do it (And then
   based on feedback work out the issues in drivers/staging). But what
   about authorship - there are mulitple authors ?

 - zcache is a bit different that the normal drivers type - and it is unclear
   yet what will be required to get it out - and both Seth and Nitin have this
   hungry look in their eyes of wanting to make it super-duper. So doing
   the work to do it - is not going to be a problem at all - just some form
   of clear goals of what we need "now" vs "would love to have".

 - folks are using it, which means continued -stable kernel back-porting.

So with that in mind I was wondering whether you would be up for:
 - me sending to you before a merge window some updates to the zcache
   as a git pull - that way you won't have to deal with a bunch of
   small patches and when there is something you don't like we can fix
   it up to your liking. The goal would be for us - Dan, Nitin, Seth and me
   working on promoting the driver out of staging and you won't have to
   be bugged every time we have a new change that might be perceived
   as feature, but is in fact a step towards mainstreaming it. I figured
   that is what you are most annoyed at - handling those uncoordinated
   requests and not seeing a clear target.

 - alongside of that, I work on making those frontswap changes folks
   have asked for. Since those changes can affect zcache, that means
   adding them in zcache alongside.

Hopefully, by the time those two items are done, both pieces can go in
the kernel at the same time-ish.
--
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