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

[Peter Williams <pwil3058@bigpond.net.au>]

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                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce