Messages in this thread | | | Date | Fri, 29 Mar 2013 12:42:53 +0530 | From | Preeti U Murthy <> | Subject | Re: [PATCH 4/5] sched: don't consider upper se in sched_slice() |
| |
Hi Joonsoo,
On 03/28/2013 01:28 PM, Joonsoo Kim wrote: > Following-up upper se in sched_slice() should not be done, > because sched_slice() is used for checking that resched is needed > whithin *this* cfs_rq and there is one problem related to this > in current implementation. > > The problem is that if we follow-up upper se in sched_slice(), it is > possible that we get a ideal slice which is lower than > sysctl_sched_min_granularity. > > For example, we assume that we have 4 tg which is attached to root tg > with same share and each one have 20 runnable tasks on cpu0, respectivly. > In this case, __sched_period() return sysctl_sched_min_granularity * 20 > and then go into loop. At first iteration, we compute a portion of slice > for this task on this cfs_rq, so get a slice, sysctl_sched_min_granularity. > Afterward, we enter second iteration and get a slice which is a quarter of > sysctl_sched_min_granularity, because there is 4 tgs with same share > in that cfs_rq. > > Ensuring slice larger than min_granularity is important for performance > and there is no lower bound about this, except timer tick, we should > fix it not to consider upper se when calculating sched_slice. >
I am assuming the sysctl_sched_latency = 20ms and sysctl_sched_min_granularity = 4ms. In that case:
With your patch, the sum of the sched_slice(runnable_task) on each_tg is 40ms = sched_min_granularity * 10, while the parent tg has a sched_slice of sysctl_sched_latency / 4 = (20 / 4) = 5ms.
Ideally the children's cpu share must add upto the parent's share.
Thank you
Regards Preeti U Murthy
| |