On Sun, Nov 18, 2012 at 3:12 AM, Preeti U Murthy <pre...@linux.vnet.ibm.com> wrote: > Hi Alex, > > On 11/17/2012 06:34 PM, Alex Shi wrote: >> This patchset try to consider runnable load avg when do cpu load comparison >> in load balance. >> >> I had seen preeti's enabling before patch finished, but I still think >> considing >> runnable load avg on rq is may a more natrual way. >> >> BTW, I am thinking if 2 times decay for cpu_load is too complicate? one for >> runnable time, another for CPU_LOAD_IDX. I think I missed the decay reason >> for CPU_LOAD_IDX. Could anyone like do me favor to give some hints of this? > > The decay happening for CPU_LOAD_IDX is *more coarse grained* than the > decay that __update_entity_runnable_avg() is performing.While > __update_cpu_load() decays the rq->load.weight *for every jiffy*(~4ms) > passed so far without update of the load, > __update_entity_runnable_avg() decays the rq->load.weight *for every > 1ms* when called from update_rq_runnable_avg(). > > Before the introduction of PJT's series,__update_cpu_load() seems to be > the only place where decay of older rq load was happening(so as to give > the older load less importance in its relevance),but with the > introduction of PJT's series since the older rq load gets decayed in > __update_entity_runnable_avg() in a more fine grained fashion,perhaps > you are right,while the CPU_LOAD_IDX gets updated,we dont need to decay > the load once again here.
If cpu_load is just a coarse decay, we can remove it. but it has different meaning for busy_idx, forkexec_idx, idle_idx, newidle_idx. each of them has different degree decay. that is the key part, but I has no idea of their value come from. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
