Messages in this thread | | | Date | Wed, 08 Jan 2014 16:32:18 +0800 | From | Alex Shi <> | Subject | Re: [RFC] sched: CPU topology try |
| |
On 01/08/2014 04:49 AM, Peter Zijlstra wrote: > On Tue, Jan 07, 2014 at 03:41:54PM +0000, Morten Rasmussen wrote: >> I think that could work if we sort of the priority scaling issue that I >> mentioned before. > > We talked a bit about this on IRC a month or so ago, right? My memories > from that are that your main complaint is that we don't detect the > overload scenario right. > > That is; the point at which we should start caring about SMP-nice is > when all our CPUs are fully occupied, because up to that point we're > under utilized and work preservation mandates we utilize idle time. > > Currently we detect overload by sg.nr_running >= sg.capacity, which can > be very misleading because while a cpu might have a task running 'now' > it might be 99% idle. > > At which point I argued we should change the capacity thing anyhow. Ever > since the runnable_avg patch set I've been arguing to change that into > an actual utilization test. > > So I think that if we measure overload by something like >95% utilization > on the entire group the load scaling again makes perfect sense.
In my old power aware scheduling patchset, I had tried the 95 to 99. But all those values will lead imbalance when we test while(1) like cases. like in a 24LCPUs groups, 24*5% > 1. So, finally use 100% as overload indicator. And in testing 100% works well to find overload since few system service involved. :) > > Given the 3 task {A,B,C} workload where A and B are niced, to land on a > symmetric dual CPU system like: {A,B}+{C}, assuming they're all while(1) > loops :-). > > The harder case is where all 3 tasks are of equal weight; in which case > fairness would mandate we (slowly) rotate the tasks such that they all > get 2/3 time -- we also horribly fail at this :-) >
-- Thanks Alex
| |