>> Removing cpu_load completely certainly makes things simpler, my worry is >> just how much was lost by doing it. I agree that cpu_load needs a >> cleanup, but I can't convince myself that just removing it completely >> and not having any longer term view of cpu load anymore is without any >> negative side-effects. > > Hi Alex, > > Have you followed this thread about load_idx and the interest of using > them to use different average period ? > https://lkml.org/lkml/2014/1/6/499
Yes, I hoped to use blocked load before. But I still can not figure out the correct usage of it. Or maybe we need more quick decay for blocked load? Or, maybe clean cpu_load is helpful to make room to reconsider this. > > Vincent > >> >> {source, target}_load() are now instantaneous views of the cpu load, >> which means that they may change very frequently. That could potentially >> lead to more task migrations at all levels in the domain hierarchy as we >> no longer have the more conservative cpu_load[] indexes that were used >> at NUMA level. >> >> Maybe some of the NUMA experts have an opinion about this? >> >> In the discussions around V1 I think blocked load came up again as a >> potential replacement for the current cpu_load array. There are some >> issues that need to be solved around blocked_load first though. >> >> Morten -- Thanks Alex -- 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/