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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/