Re: [ckrm-tech] Re: [patch 0/8] CKRM: Core patch set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Diego Calleja wrote:
El Tue, 29 Mar 2005 22:05:30 -0800,
Paul Jackson <[email protected]> escribió:



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, and
although 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 the
amount of concepts created to achieve that is too huge and too complex.


Certainly there's scope for improvement in the implementation of the CPU controller but the solution you propose works by redefining the problem.

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.

Doing performance isolation at the granularity of users and groups may be useful but is not enough for workload management needs. There, it is essential that a a) flexible b) dynamic grouping of processes be controllable in their resource consumption as an aggregate. Tying that grouping to user/groups will not suffice.

CKRM's definition of class can be made equivalent to a user or group but not vice versa. Hence the more generic classes are being used, rather than reusing groups/users.

Also, our earlier prototype for the CPU controller had shown a 0.14-0.63us overhead which remained constant with increasing number of processes. While we don't have measurements for later versions, the overhead figures are by no means unacceptably high if one values the additional generality of CKRM's class (over groups/users).




Say, we "attach" group foo to nice level -5. All users who belong to group foo will have
permissions to renice themselves to nice -5. If instead of that, group foo has been
attached 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 have
zero performance impact at runtime - CRKM touches hot paths in the scheduler
I think, this would just touch a few non-critical places - because we'd just use a existing
concept.


Sure, this can't guarantee that a group will get reserved exactly 57% of  the CPU, but I
think that such level of detail is unnecesary

For desktop users, perhaps. For server workload management, this level of detail is necessary. As stated earlier, CKRM's design satisfies both.

- instead we let the kernel uses the
standard internal mechanisms to do the dirty job based in the distinction between
standard nice levels. (And we could get that level of detail just by modifying the
scheduler algorithm and adding a range of -50...0...50 nice levels ;)

For the CPU resources, we already have nice levels. The existing algorithms can already
handle priorities with them. CKRM alternative seems to be to add a second scheduling
algorithm which in super-hot paths like the ones from sched.c are, it will probably have a
performance impact. In my very humble opinion, I think we should reuse existing UNIX
concepts and combine them to achieve some of the goals CKRM tries to achieve in
a much simpler (unixy ;) way.

Not that other Unix's design decisions should influence Linux but every other enterprise UNIX has some equivalent of CKRM's classes available. So the design is far from being non-unixy :-)


-- Shailabh

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux