Date:	Thu, 3 Nov 2011 01:32:54 +0100
From:	Andrea Arcangeli <aarcange@...hat.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Cyclonus J <cyclonusj@...il.com>,
	Sasha Levin <levinsasha928@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	David Rientjes <rientjes@...gle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-mm@...ck.org, LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Konrad Wilk <konrad.wilk@...cle.com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Seth Jennings <sjenning@...ux.vnet.ibm.com>, ngupta@...are.org,
	Chris Mason <chris.mason@...cle.com>, JBeulich@...ell.com,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	Jonathan Corbet <corbet@....net>
Subject: Re: [GIT PULL] mm: frontswap (for 3.2 window)

On Wed, Nov 02, 2011 at 12:06:02PM -0700, Dan Magenheimer wrote:
> First, let me apologize for yesterday.  I was unnecessarily
> sarcastic and disrespectful, and I am sorry.  I very much appreciate
> your time and discussion, and good hard technical questions
> that have allowed me to clarify some of the design and
> implementation under discussion.

No problem, I know it must be frustrating to wait so long to get
something merged.

Like somebody already pointed out (and I agree) it'd be nice to get
the patches posted to the mailing list (with git send-emails/hg
email/quilt) and get them merged into -mm first.

About the subject, git is a super powerful tool, its design saved our
day with kernel.org too. Awesome backed design (I have to admit way
better then mercurial backend in the end, well after the packs have
been introduced) [despite the user interface is still horrible in my
view but it's very well worth the pain to learn to take advantage of
the backend]. The pulls are extremely scalable way to merge stuff, but
they tends to hide stuff and the VM/MM is such a critical piece of the
kernel that in my view it's probably better to go through the pain of
patchbombing linux-mm (maybe not lkml) and pass through -mm for
merging. It's a less scalable approach but it will get more eyes on
the code and if just a single bug is noticed that way, we all win. So
I think you could try to submit the origin/master..origin/tmem with
Andrew and Hugh in CC and see if more comments showup.

> I agree this email is too long, though it has been very useful.

Sure useful to me. I think it's normal and healthy if it gets down to
more lowlevel issues and long emails... There are still a couple of
unanswered issues left in that mail but they're not major if it can be
fixed.

> Confirmed.  Anything below the "struct frontswap_ops" (and
> "struct cleancache_ops), that is anything in the staging/zcache
> directory, is wide open for your ideas and improvement.
> In fact, I would very much welcome your contribution and
> I think IBM and Nitin would also.

Thanks. So this overall sounds fairly positive (or at least better
than neutral) to me.

The VM camp is large so I'd be nice to get comments from others too,
especially if they had time to read our exchange to see if their
concerns were similar to mine. Hugh's knowledge of the swap path would
really help (last time he added swapping to KSM).

On my side I hope it get improved over time to get the best out of
it. I've not been hugely impressed so far because at this point in
time it doesn't seem a vast improvement in runtime behavior compared
to what zram could provide, like Rik said there's no iov/SG/vectored
input to tmem_put (which I'd find more intuitive renamed to
tmem_store), like Avi said ramster is synchronous and not good having
to wait a long time. But if we can make these plugins stackable and we
can put a storage backend at the end we could do
storage+zcache+frontswap.

It needs to have future potential to be worthwhile considering it's
not self contained and modifies the core VM actively in a way that
must be maintained over time. I think I already clarified myself well
enough in prev long email to explain what are the reasons that would
made like it or not. And well if I don't like it, it wouldn't mean it
won't get merged, like wrote in prev mail it's not my decision and I
understand the distro issues you pointed out.

Now that you cleared the fact there is no API/ABI in the
staging/zcache directory to worry about, frankly I'm a lot more happy,
I thought at some point Xen would get into the equation in the tmem
code. So I certainly don't want to take the slightest risk of stifling
innovation saying no to something that makes sense and is free to
evolve :).
--
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