> worth having. I for one am a CKRM skeptic, so won't be much help to you> in that quest. Good luck.> > I don't see any performance numbers, either on small systems, or> scalability on large systems. Certainly this patch does not fall under> the "obviously no performance impact" exclusion.

I'm one of those people who also thinks that CKRM tries to do too much things, andalthough my opinion doesn't counts a lot, I'll try to explain myself anyway :)

One of the things I personally don't like about CKRM its how it handles "CPU resources".The goal of CKRM seems to be "control how much % a process can get get", but theamount of concepts created to achieve that is too huge and too complex. For the"CPU resources", I think that there're much simpler and better solutions. For example,instead what CRKM proposes I propose a simpler concept: "attaching" GIDs to a niceness level.

Say, we "attach" group foo to nice level -5. All users who belong to group foo will havepermissions to renice themselves to nice -5. If instead of that, group foo has beenattached at nice level 15, all processes from users who belong to foo will be run at 15,and they won't be able to renice themselves even to the default priority (0)

This should be very easy to implement, and what's more important, it'd probably havezero performance impact at runtime - CRKM touches hot paths in the schedulerI think, this would just touch a few non-critical places - because we'd just use a existingconcept.

Sure, this can't guarantee that a group will get reserved exactly 57% of the CPU, but Ithink that such level of detail is unnecesary - instead we let the kernel uses thestandard internal mechanisms to do the dirty job based in the distinction betweenstandard nice levels. (And we could get that level of detail just by modifying thescheduler algorithm and adding a range of -50...0...50 nice levels ;)

For the CPU resources, we already have nice levels. The existing algorithms can alreadyhandle priorities with them. CKRM alternative seems to be to add a second schedulingalgorithm which in super-hot paths like the ones from sched.c are, it will probably have aperformance impact. In my very humble opinion, I think we should reuse existing UNIXconcepts and combine them to achieve some of the goals CKRM tries to achieve ina much simpler (unixy ;) way.-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at http://www.tux.org/lkml/