Re: 2.6.13-rc3-mm1 (ckrm)

[Paul Jackson <pj@sgi.com>]

Matthew wrote:
> I don't see the large ifdefs you're referring to in -mm's
> kernel/sched.c.

Perhaps someone who knows CKRM better than I can explain why the CKRM
version in some SuSE releases based on 2.6.5 kernels has substantial
code and some large ifdef's in sched.c, but the CKRM in *-mm doesn't.
Or perhaps I'm confused.  There's a good chance that this represents
ongoing improvements that CKRM is making to reduce their footprint
in core kernel code.  Or perhaps there is a more sophisticated cpu
controller in the SuSE kernel.


> Have you looked at more
> recent benchmarks posted on CKRM-Tech around April 15th 2005?
> ...
> http://ckrm.sourceforge.net/downloads/ckrm-ols04-slides.pdf 

I had not seen these before.  Thanks for the pointer.


> The Rule-Based Classification Engine (RBCE) makes CKRM useful
> without middleware.

I'd be encouraged more if this went one step further, past pointing
out that the API can be manipulated from the shell without requiring C
code, to providing examples of who intends to _directly_ use this
interface. The issue is perhaps less whether it's API is naturally C or
shell code, or more of how many actual, independent, uses of this API
are known to the community.  A non-trivial API and mechanism that
is de facto captive to a single middleware implementation (which
may or may not apply here - I don't know) creates an additional review
burden, because some of the natural forces that guide us to healthy
long lasting interfaces are missing.  If that concern applies here,
it's certainly not insurmountable - but it should in my view raise the
review barrier to acceptance.  If other middleware or direct users
are not essentially performing some of the review for us, we have to do
it here with greater thoroughness.


> If you could be more specific I'd be able to
> respond in less general and abstract terms.

Good come back <grin>.

I made an effort along these lines last year, in the thread
I referenced a few days ago:

    Classes: 1) what are they, 2) what is their name?
    http://sourceforge.net/mailarchive/forum.php?thread_id=5328162&forum_id=35191

I doubt that it I have much more to contribute along
these lines now.

Sorry.

> I haven't seen this limitation [128 cpus] ...

Good - I presume that there is no longer, if there ever was, such a
limitation.

Thanks for you reply.

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