Re: [RFC 2/5] sched: Add CPU rate soft caps

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

 



Peter Williams wrote:
Kirill Korotaev wrote:
I think more needs to be said about the fairness issue.

1. If a task is getting its cap or more then it's getting its fair share as specified by that cap. Yes?

2. If a task is getting less CPU usage then its cap then it will be being scheduled just as if it had no cap and will be getting its fair share just as much as any task is.

So there is no fairness problem.
the problem is that O(1) cpu scheduler doesn't keep the history of execution and consumed time which is required for fairness. So I'm pretty sure, that fairness will decrease when one of the tasks is being capped/uncapped constanntly.

Why would you want to keep capping and uncapping a task?


Can you check the behavior of 2 tasks, having different priorites with the range of possible cpu limits implied on one of them.

It works OK.


I tend to test by observing the results of setting caps on running tasks and this doesn't generate something that can be e-mailed.
plot?

Plot what? I'll see if I can come up with some tests that have plottable results. Unless you already have some that I could use?


Observations indicate that hard caps are enforced to less than 1% and ditto for soft caps except for small soft caps where the fact (stated in the patches) that enforcement is not fully strict in order to prevent priority inversion or starvation means that the cap is generally exceeded. I'm currently making modifications (based on suggestions by Con Kolivas) that implement an alternative method for avoiding priority inversion and starvation and allow the enforcement to be more strict.
running tasks are also not very good for such testing. it is too simple load. It would be nice if you could test the results with wide range of limits on Java Volano benchmark (loopback mode).

I'm interested in three things:

1. that the capping works pretty well,
2. that if the capping code is present in the kernel but no tasks are actually capped then the extra over head is minimal, and
3. that if capping is used then the overhead involved is minimal.

I do informal checks for 1), use kernbench to test 2) (know noticeable

I'm having a bad day word selection wise that "know" should be "no".

overhead has been observed) and haven't been able to think of a way to test 3) yet as applying caps small enough that they'd actually be enforced to something like kernbench would clearly cause it to take longer :-(.

Feel free to run any other tests that you think are necessary.

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