[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d5104e62-0783-4af2-8892-d5a8ecc123a4@default>
Date: Tue, 1 Nov 2011 14:32:48 -0700 (PDT)
From: Dan Magenheimer <dan.magenheimer@...cle.com>
To: Dave Hansen <dave@...ux.vnet.ibm.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>,
John Stoffel <john@...ffel.org>,
Johannes Weiner <jweiner@...hat.com>,
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,
Jonathan Corbet <corbet@....net>
Subject: RE: [GIT PULL] mm: frontswap (for 3.2 window)
> From: Dave Hansen [mailto:dave@...ux.vnet.ibm.com]
> Subject: RE: [GIT PULL] mm: frontswap (for 3.2 window)
>
> On Tue, 2011-11-01 at 11:10 -0700, Dan Magenheimer wrote:
> > Case A) CONFIG_FRONTSWAP=n
> > Case B) CONFIG_FRONTSWAP=y and no tmem backend registers
> > Case C) CONFIG_FRONTSWAP=y and a tmem backend DOES register
> ...
> > The point is that only Case C has possible interactions
> > so Case A and Case B end-users and kernel developers need
> > not worry about the maintenance.
>
> I'm personally evaluating this as if all the distributions would turn it
> on. I'm evaluating as if every one of my employer's systems ships with
> it and as if it is =y my laptop. Basically, I'm evaluating A/B/C and
> only looking at the worst-case maintenance cost (C). In other words,
> I'm ignoring A/B and assuming wide use.
Good. Me too. I was just saying that the-company-that-must-not-
be-named (from which most of the non-technical objections are
coming), can choose A or B as they wish without any impact
to their developers or users.
> I'm curious where you expect to see the code get turned on and used
> since we might be looking at this from different angles.
I think we are on the same page. Oracle is turning it on (case B)
in the default UEK kernel, for which the Beta git tree is published.
Corporate policy keeps me from saying anything in detail about
pre-released products, but you saw that our Oracle VM manager
responded to this thread, so I'll leave that to your imagination.
I think we agreed offlist that zcache is not ready for prime-time
and a good measure of when it _will_ be ready is when it is
promoted out of staging. I'm really hoping you guys at IBM
will drive that (and am willing to get out of the way if you
prefer).
There's a lot of interest in Oracle in RAMster (which I personally
think is very sexy), but I haven't been able to make forward progress
in nearly three months now due to other fires and commitments. :-(
So are we on the same page?
Thanks,
Dan
--
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