Messages in this thread | | | Date | Sat, 03 Jun 2006 10:08:57 +1000 | From | Peter Williams <> | Subject | Re: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps |
| |
Mike Galbraith wrote: > On Fri, 2006-06-02 at 23:18 +1000, Peter Williams wrote: >> Mike Galbraith wrote: >>> On Fri, 2006-06-02 at 15:55 +1000, Peter Williams wrote: >>>> Chandra Seetharaman wrote: >>>>> On Thu, 2006-06-01 at 14:04 +0530, Balbir Singh wrote: >>>>>> Hi, Kirill, >>>>>> >>>>>> Kirill Korotaev wrote: >>>>>>>> Do you have any documented requirements for container resource >>>>>>>> management? >>>>>>>> Is there a minimum list of features and nice to have features for >>>>>>>> containers >>>>>>>> as far as resource management is concerned? >>>>>>> Sure! You can check OpenVZ project (http://openvz.org) for example of >>>>>>> required resource management. BTW, I must agree with other people here >>>>>>> who noticed that per-process resource management is really useless and >>>>>>> hard to use :( >>>>> I totally agree. >>>> "nice" seems to be doing quite nicely :-) >>>> >>>> To me this capping functionality is a similar functionality to that >>>> provided by "nice" and all that's needed to make it useful is a command >>>> (similar to "nice") that runs tasks with caps applied. >>> Similar in that they are both inherited. Very dissimilar in that the >>> effect of nice is not altered by fork whereas the effect of a cap is. >>> >>> Consider make. A cap on make itself isn't meaningful, and _any_ per >>> task cap you put on it with the intent of managing the aggregate, is >>> defeated by the argument -j. Per task caps require omniscience to be >>> effective in managing processes. That's a pretty severe limitation. >> These caps aren't trying to control aggregates but with suitable >> software they can be used to control aggregates. > > How? How would you deal with the make example with per task caps.
I'd build a resource management tool that uses task statistics, nice and caps to manage CPU resource allocation. This could be a plug in kernel module or a user space daemon. It doesn't need to be in the scheduler.
Peter -- Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce - 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/
| |