"Jan H. Schönherr" <schn...@cs.tu-berlin.de> writes: > Hi Paul. > > Am 23.08.2012 16:14, schrieb p...@google.com: >> Please find attached the latest version for CFS load-tracking. > > Originally, I thought, this series also takes care of > the leaf-cfs-runqueue ordering issue described here: > > http://lkml.org/lkml/2011/7/18/86 > > Now, that I had a closer look, I see that it does not take > care of it. > > Is there still any reason why the leaf_cfs_rq-list must be sorted? > Or could we just get rid of the ordering requirement, now?
Ideally yes, since a parent's __update_cfs_rq_tg_load_contrib and update_cfs_shares still depend on accurate values in runnable_load_avg/blocked_load_avg from its children. That said, nothing should completely fall over, it would make load decay take longer to propogate to the root. > > (That seems easier than to fix the issue, as I suspect that > __update_blocked_averages_cpu() might still punch some holes > in the hierarchy in some edge cases.) Yeah, I suspect it's possible that the parent ends up with a slightly lower runnable_avg_sum if they're both hovering around the max value since it isn't quite continuous, and it might be the case that this difference is large enough to require one more tick to decay to zero. -- 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/