Re: [Lse-tech] Re: [PATCH] cpusets - big numa cpu and memory placement

[Paul Jackson <pj@sgi.com>]

Matthrew, responding to Paul:
> > If for whatever reason, you don't think it is worth the effort to morph
> > the virtual resouce manager that is currently embedded within CKRM into
> > an independent, neutral framework, then don't expect the rest of us to
> > embrace it.  Do you think Reiser would have gladly used vfs to plug in
> > his file system if it had been called "ext"?  In my personal opinion, it
> > would be foolhardy for SGI, NEC, Bull, Platform (LSF) or Altair (PBS) to
> > rely on critical technology so clearly biased toward and dominated by a
> > natural competitor.
> 
> I don't think that is terribly fair.  I can honestly say that I'm not
> opposing your implementation because of who you work for. 

Good point.  I was painting with too wide a brush (hmmm ... someday I
should see if I can get through an entire post without an analogy ...)

When people show a good ability to work with others on lkml who have a
shared interest and sufficient competence in an area, then it doesn't
much matter what company they work for.  I see such a discussion
happening on another portion of this thread, with yourself, Nick, Peter
and Erich, involving the domain scheduler.  That works well.

So far I have been unable to achieve confidence in my ability to
interact well with the key CKRM folks.  In various ways, I have found
their project, and their demeanor on this list, to be difficult for me
to approach.

Normally this wouldn't matter.  However Andrew and others have proposed
that cpusets have a critical dependency on CKRM.  Now it matters.

If I am to have a critical project dependency on an external group with
whom I lack confidence that we share sufficient common interest and a
healthy ability to communicate, then I prefer a more adversarial style
of relations, with explicit contracts, minimum clearly defined and
verifiable deliverables, and suitable fallback contingencies in place.
I keep a sharp eye out for potential conflicts of interest.

My suggestion to separate the virtual resource management framework
(which I named 'vrm') from CKRM's other elements, such as fair share
scheduling, was an attempt to establish such a minimum verifiable
deliverable.  That suggestion was clearly dead on arrival.

My apologies for implicating everyone whose email ends in "ibm.com" in
my earlier comment.  IBM is a big place, and all manner and variety
of people work there.  It's a pleasure working with yourself, Matthew,
and many others from IBM.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373