lkml.org 
[lkml]   [2006]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ckrm-tech] [RFC 3/5] sched: Add CPU rate hard caps
    On Fri, Jun 02, 2006 at 04:47:19PM +0200, Mike Galbraith wrote:
    > > > 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.

    If we add some grouping mechanism for tasks (CKRM or PAGG), then this
    could be handled easily by adjusting the per-task limit based on the
    number of tasks in the group? For example, when make is started, it
    could be the only task in the group, with a per-task (& group_limit) of 50%.
    As it forks more tasks, the per-task limit of everyone in the group is
    adjusted (lazily perhaps at the next scheduler tick time) based on the
    group_limit/num_of_tasks_in_group.

    This would still require a resource control daemon to adjust the
    per-task limit of tasks within a group (if some task in underutilizing
    its bandwidth for example).


    --
    Regards,
    vatsa
    -
    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/

    \
     
     \ /
      Last update: 2006-06-06 13:29    [W:2.407 / U:0.464 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site