From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Seth Jennings <sjenning@linux.vnet.ibm.com>
Cc: Dan Magenheimer <dan.magenheimer@oracle.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
Mel Gorman <mgorman@suse.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Nitin Gupta <ngupta@vflare.org>, Minchan Kim <minchan@kernel.org>,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Robert Jennings <rcj@linux.vnet.ibm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
devel@driverdev.osuosl.org
Subject: Re: [RFC] mm: add support for zsmalloc and zcache
Date: Tue, 25 Sep 2012 14:33:01 +0400 [thread overview]
Message-ID: <1348569181.2457.26.camel@dabdike> (raw)
In-Reply-To: <50609794.8030508@linux.vnet.ibm.com>
On Mon, 2012-09-24 at 12:25 -0500, Seth Jennings wrote:
> In summary, I really don't understand the objection to
> promoting zcache and integrating zcache2 improvements and
> features incrementally. It seems very natural and
> straightforward to me. Rewrites can even happen in
> mainline, as James pointed out. Adoption in mainline just
> provides a more stable environment for more people to use
> and contribute to zcache.
This is slightly disingenuous. Acceptance into mainline commits us to
the interface. Promotion from staging with simultaneous deprecation
seems like a reasonable (if inelegant) compromise, but the problem is
it's not necessarily a workable solution: as long as we have users of
the interface in mainline, we can't really deprecate stuff however many
feature deprecation files we fill in (I've had a deprecated SCSI ioctl
set that's been deprecated for ten years and counting). What worries me
looking at this fight is that since there's a use case for the old
interface it will never really get removed.
Conversely, rewrites do tend to vastly increase the acceptance cycle
mainly because of reviewer fatigue (and reviews are our most precious
commodity in the kernel). I'm saying rewrites should be possible in
staging because it was always possible on plain patch submissions; I'm
not saying they're desirable. Every time I've seen a rewrite done, it
has added ~6mo-1yr to the acceptance cycle. I sense that the fatigue
factor with transcendent memory is particularly high, so we're probably
looking at the outside edge of the estimate, so the author needs
seriously to consider if the rewrite is worth this.
Oh, and while this spat goes on, the stalemate is basically assured and
external goodwill eroding. So, for god's sake find a mutually
acceptable compromise, because we're not going to find one for you.
James
--
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>
next prev parent reply other threads:[~2012-09-25 10:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 21:34 [RFC] mm: add support for zsmalloc and zcache Seth Jennings
2012-09-21 16:12 ` Mel Gorman
2012-09-21 18:02 ` Konrad Rzeszutek Wilk
2012-09-21 19:02 ` Seth Jennings
2012-09-21 20:35 ` Dan Magenheimer
2012-09-22 1:07 ` Mel Gorman
2012-09-22 21:18 ` Dan Magenheimer
2012-09-24 10:31 ` Mel Gorman
2012-09-24 20:36 ` Dan Magenheimer
2012-09-25 10:20 ` Mel Gorman
2012-09-23 7:34 ` James Bottomley
2012-09-24 20:05 ` Dan Magenheimer
2012-09-24 17:25 ` Seth Jennings
2012-09-24 19:17 ` Dan Magenheimer
2012-09-27 20:25 ` Seth Jennings
2012-09-27 22:07 ` Dan Magenheimer
2012-10-02 18:02 ` Seth Jennings
2012-10-02 18:17 ` Dan Magenheimer
2012-10-04 14:36 ` Seth Jennings
2012-10-26 21:45 ` Seth Jennings
2012-11-02 16:14 ` Konrad Rzeszutek Wilk
2012-09-25 10:33 ` James Bottomley [this message]
2012-09-21 19:14 ` Dan Magenheimer
2012-09-22 0:25 ` Mel Gorman
2012-09-22 13:31 ` Sasha Levin
2012-09-22 13:38 ` Sasha Levin
2012-09-25 19:22 ` Dan Magenheimer
2012-09-21 19:16 ` Seth Jennings
[not found] <<1346794486-12107-1-git-send-email-sjenning@linux.vnet.ibm.com>
2012-09-06 20:37 ` Dan Magenheimer
2012-09-07 14:37 ` Konrad Rzeszutek Wilk
2012-09-09 3:46 ` Nitin Gupta
2012-09-17 20:42 ` Dan Magenheimer
2012-09-17 23:46 ` Nitin Gupta
2012-09-07 17:31 ` Seth Jennings
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=1348569181.2457.26.camel@dabdike \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=dan.magenheimer@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=rcj@linux.vnet.ibm.com \
--cc=sjenning@linux.vnet.ibm.com \
--cc=xiaoguangrong@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).