From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Magenheimer Subject: RE: [PATCH] [linux-2.6.39.x for xen] tmem: self-ballooning and frontswap-selfshrinking Date: Tue, 7 Jun 2011 09:59:03 -0700 (PDT) Message-ID: References: <292df482-2d4c-4a4f-b5f4-4c808692156e@default> <1307439243.775.535.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1307464812.775.665.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Campbell Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Konrad Wilk , Vasiliy G Tolstov , JBeulich@novell.com, Dushmanta Mohapatra List-Id: xen-devel@lists.xenproject.org > From: Ian Campbell [mailto:Ian.Campbell@eu.citrix.com] > > > > Although you're right, as I am fresh off a 2-1/2 year odyssey of > > upstreaming cleancache, AND since this is almost certainly Xen > > specific AND since there will likely be some changes over time > > which could conceivably make this unnecessary, I would be content > > with carrying this in a Xen-only tree for the foreseeable future. >=20 > As someone who is fresh of a 5+ year odyssey of upstreaming a Xen-only > tree into mainline I must strongly object to this approach. >=20 > We have had a long uphill battle to get ourselves to the state we are in > today and the approach you are suggesting is absolutely counter to the > philosophy we have built up whilst doing that and accepting this undoes > all of the good work up until now. >=20 > Getting stuff into a Xen tree is not an aim in and of itself but merely > a conduit towards upstream. Nothing should be going into the Xen stable > trees with the explicit aim of staying there for the foreseeable future. >=20 > If you want to run a tmem-only tree with stuff you don't intend to send > upstream yet in it then that is your prerogative, please don't ask the > rest of us to carry that burden. Well that's a bit harsh. Perhaps I should clarify: By "for the foreseeable future", I meant I don't expect it to be a candidate for 3.1 or probably even 3.2. I didn't mean to imply that I wasn't going to try, just that I wasn't going to try for 3.1. I see Konrad's tree as kind of a linux-next specific to Xen where Xen-ish functionality/fixes can be exposed "officially" to Xen users before the upstreaming battle is fought. I've had many requests for tmem over the last couple of years but haven't had a good foundation for delivery. Are you saying nothing should go in Konrad's tree unless it is immediately upstreamable? Related, there's a really good article* in lwn.net of James Bottomley's talk about the Android fork (subscribers only as of now) that I think nicely summarizes our frustration with upstreaming battles. Dan * http://lwn.net/Articles/446297/ ... This may not be public for a week or two.