Srivatsa Vaddagiri wrote:
On Sun, Jun 18, 2006 at 08:25:02PM +1000, Peter Williams wrote:
People are going to want to extend this to capping a *group* of tasks, with
some yet-to-be-determined means of tying those tasks together. How well
suited is this code to that extension?
Quite good. It can be used from outside the scheduler to impose caps on
arbitrary groups of tasks. Were the PAGG interface available I could
knock up a module to demonstrate this. When/if the "task watchers"
For demonstration purpose, maybe you could use tsk->uid to group tasks and
and see how capping at group level works out? Basically cap the per-user cpu
usage.
I was thinking of doing the group of tasks that represent a process's
threads as a first example as that will be more useful to ordinary users
as well as demonstrating the technique.
patch is included I will try and implement a higher level mechanism
using that. The general technique is to get an estimate of the
"effective number" of tasks in the group (similar to load) and give each
task in the group a cap which is the group's cap divided by the
effective number of tasks (or the group cap whichever is smaller -- i.e.
the effective number of tasks could be less than one).
For "effective number" do you include only runnable tasks?
It would be roughly equivalent to a smoothed smoothed estimate of the
number of runnable tasks in the group.
As and when
this number changes, you would need to go and change the per-task cap of
all tasks in the group. Any idea what the cost of that operation would
be? Or do you intend to do it lazily to amortize some of that cost?
Yes. It would be some form of periodical sampling mechanism. It could
be done from user space or from a module.
The costs can also be reduced by realizing that it is only necessary to
do anything at all if the number of tasks in the group is greater than
the group's cap. I.e. if a group has a cap of 3000 but only two tasks
there is no way the group can exceed its cap so that group can be ignored.
Doing it inside the scheduler is also doable but would have some locking
issues. The run queue lock could no longer be used to protect the data
as there's no guarantee that all the tasks in the group are associated
with the same queue.
--
Peter Williams [email protected]
"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 [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]
