RE: [Xen-devel] [PATCH] [linux-2.6.39.x for xen] tmem: self-ballooning and frontswap-selfshrinking

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Tue, 2011-06-07 at 17:59 +0100, Dan Magenheimer wrote:
> > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxxxxx]
> > >
> > > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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.
> > 
> > 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 think that's fine, but your initial statement sounded a lot less
positive and had me quite worried. The old attitude of getting something
into the Xen tree as an end goal and leaving the rest to someone else
(or no one at all) is something which needs to be stomped on hard (I'm
talking more generally now, you've explained this specific case)

> 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.

linux-next is very specifically about stuff which is ready for the next
merge window, i.e. stuff which a maintainer intends to send along to
Linus when the merge window opens. It is also explicitly not for works
in progress. You have a tree in linux-next so I assume you have seen and
read Stephen's boilerplate intro.

I think that exposing Xen users to features which have not been proposed
upstream (whether due to fears of "battles" or otherwise) does neither
our users nor us any favours in the long run.

Once things are exposed to users in an official way they begin to build
expectations and requirements and when such features are subsequently
taken upstream it is trying to retain these while addressing upstream
concerns and requests for change which is one of the most frequent
sources of so called battles and other tensions.

The specific hunk which spawned this sub-thread (exporting something
from mm/mmap.c) is exactly the sort of change which can lead to tension
if it is not discussed with the mm maintainers early on.

IMHO it is much better to simply work with upstream, with upstreaming in
mind from day one and to release early and often to LKML and to
encourage Xen contributors (who are really Linux contributors in this
context) to behave in that way also.

> I've had many requests
> for tmem over the last couple of years but haven't had a good
> foundation for delivery.

Every developer always has the option of setting up a git tree and
publishing specific branches or of posting regular patch kits on LKML
etc etc. That is how everyone treats their development work without
asking for it to be included in a subsystem tree before it is actually
ready or has been through review etc.

>   Are you saying nothing should go in
> Konrad's tree unless it is immediately upstreamable?

It is up to Konrad what he includes in his tree.

I think the main thing here is to stop thinking in terms of Xen and
"upstream" trees as separate things. The Linux trees which Xen
maintainers publish are part of the upstream workflow as much as the
tip.git or block/net subsystem maintainer's trees and should be treated
as such. There really should be no _concept_ of an official Xen tree
other than as part of the flow from contributors to upstream. IOW there
would ideally only be the various Xen maintainer's linux-next branches
and nothing more official than that.

However if we really feel there is a need for there to be branches
(whichever tree they live in) which we (test and) bless as official
Xen.org trees then I think we should aim to be as close to upstream as
we are able (and these days we are in a very good position to achieve
this aim) and that means those branches are effectively equivalent to
either a linux-next style branch where patches in that tree are believed
to be stable and ready for upstream or a stable/longterm style branch
containing backports of already upstreamed patches (in the case of base
versions maintained for longer than normal term).

So in the case of official branches, yes, I think its contents should,
by definition, be ready for upstream.

I originally wrote about this need to switch how we as a community
thinks about "Linux upstream" last year, see:
http://lists.xensource.com/archives/html/xen-devel/2010-10/msg00078.html
I don't think anything much has changed except that we are in an even
better position WRT upstream so the arguments for working with upstream
first and foremost are even stronger.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel