Re: [RFC 3/5] sched: Add CPU rate hard caps

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

 



Kirill Korotaev wrote:
Using a timer for releasing tasks from their sinbin sounds like a  bit
of an overhead. Given that there could be 10s of thousands of tasks.



The more runnable tasks there are the less likely it is that any of them is exceeding its hard cap due to normal competition for the CPUs. So I think that it's unlikely that there will ever be a very large number of tasks in the sinbin at the same time.

for containers this can be untrue...


Why will this be untrue for containers?
if one container having 100 running tasks inside exceeded it's credit, it should be delayed. i.e. 100 tasks should be placed in sinbin if I understand your algo correctly. the second container having 100 tasks as well will do the same.

1. Caps are set on a per task basis not on a group basis.
2. Sinbinning is the last resort and only used for hard caps. The soft capping mechanism is also applied to hard capped tasks and natural competition also tends to reduce usage rates.

In general, sinbinning will only kick in on lightly loaded systems where there is no competition for CPU resources.

Further, there is a natural ceiling of 999 per CPU on the number tasks that will ever be in the sinbin at the same time. To achieve this maximum some very unusual circumstances have to prevail:

1. these 999 tasks must be the only runnable tasks on the system,
2. they all must have a cap of 1/1000, and
3. the distribution of CPU among them must be perfectly fair so that they all have the expected average usage rate of 1/999.

If you add one more task to this mix the average usage would be 1/1000 and if they all had that none would be exceeding their cap and there would be no sinbinning at all. Of course, in reality, half would be slightly above the average and half slightly below and about 500 would be sinbinned. But this reality check also applies to the 999 and somewhat less than 999 would actually be sinbinned.

As the number of runnable tasks increases beyond 1000 then the number that have a usage rate greater than their cap will decrease and quickly reach zero.

So the conclusion is that the maximum number of sinbinned tasks per CPU is given by:

min(1000 / min_cpu_rate_cap - 1, nr_running)

As you can see, if a minimum cap cpu of 1 causes problems we can just increase that minimum.

And once again I ask what's so special about containers that changes this?

Peter
--
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]
  Powered by Linux