Preeti Murthy <preeti.l...@gmail.com> writes: > Hi Paul, Ben, > > A few queries regarding this patch: > > 1.What exactly is the significance of introducing sched_avg structure > for a runqueue? If I have > understood correctly, sched_avg keeps track of how long a task has > been active, > how long has it been serviced by the processor and its lifetime.How > does this apply analogously > to the runqueue?
Remember that sched_avg's are not just for tasks, they're for any CFS group entity (sched_entity), for which they track the time runnable and the time used, which allows the system-wide per-task_group computation of runnable and usage. Computing these on the root has no usage in this patchset, but any extensions of this using hierarchy-based fractional usage or runnable time would need it, and retrofitting it afterwards would be a pain. > > 2.Is this a right measure to overwrite rq->load.weight because the > rq->sched_avg does not seem to > take care of task priorities.IOW, what is the idea behind > introducing this metric for the runqueue? > Why cant the run queue load be updated the same way as the cfs_rq > load is updated: > cfs_rq->runnable_load_avg and cfs_rq->blocked_load_avg. Loadwise you would indeed want the cfs_rq statistics, that is what they are there for. The sched_avg numbers are only useful in computing the parent's load (irrelevant on the root), or for extensions using raw usage/runnable numbers. > > 3.What is the significance of passing rq->nr_running in > enqueue_task_fair while updating > the run queue load? Because __update_entity_runnable_avg does not > treat this argument > any differently if it is >1. That could just as well be rq->nr_running != 0, it would behave the same. -- 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/
