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 [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]
