Messages in this thread | | | Date | Thu, 21 Jul 2005 16:32:27 -0700 | From | Paul Jackson <> | Subject | Re: 2.6.13-rc3-mm1 (ckrm) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |