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

[Matthew Dobson]

On Fri, 2004-10-08 at 11:23, Paul Jackson wrote:
> CKRM aspires to be both a general purpose resource management framework
> and the embodiment of fair share scheduling.

I think your missing something here.  CKRM, as I understand it, aspires
to be a general purpose resource management framework.  To that point I
will accede.  But the second part, about CKRM being the embodiment of
fair share scheduling, is secondary.  That is simply one of it's
potential functions as a general purpose resource management framework. 
It could also be the embodiment of unfair scheduling, if you choose to
implement such a resource controller.  It wouldn't be very useful, but
it could be a fun exercise! ;)


> 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.  I could care
less.  I'm opposing it because I think I've got an alternative that can
offer the same functionality with less impact.  I don't work on CKRM,
and when I wrote my code CKRM was not even on my radar.  If
sched_domains will play nicer with CKRM than cpusets, thats just a
bonus.  I certainly didn't design it that way!


> When someone offers you an open door ("Keep talking"), don't slam it in
> their face.  It might not open again.

*More* analogies!?! ;)


> ... keep talking ...

I warned you!

-Matt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/