On Tue, Aug 20, 2013 at 02:32:46AM -0700, Jason Low wrote: > Hi Peter, > > So this is my sample implementation of the concept of matching the CPU's > avg_idle > with the maximum time we ever spend in a new idle load balance for each > domain. > This is based on our previous patch which compares avg_idle with sd->avg_cost, > but I replaced sd->avg_cost with sd->max_cost. > > Since we are comparing avg_idle with sd->max_cost, the existing avg_idle > would > not be accurate since it is limited based on migration_cost, so I increased > the > max avg_idle to 25*sched_migration_cost.
One thing we can do is make that independent of sched_migration_cost and stretch it dynamically to be 2*max_idle_balance_cost or somesuch. That would avoid the magic number and make it work for machines that are much 'slower' than yours as well. > Additionally, I updated avg_idle by > calling update_avg() first. Then if the avg_idle exceeds the max, the > avg_idle > is set to the max. This is to prevent avg_idle from being set to the maximum > after 1 long idle. Fully agreed, this is something we should do regardless -- for as long as we preserve the avg_idle() machinery anyway :-) > Since I have found idle balance to be beneficial when it is not failing to > move > tasks, I was thinking we can also not skip newidle balance (regardless of > what > avg_idle and max_cost are) if the previous attempt on the rq or domain > succeeded in moving tasks. I was also wondering if we should periodically > reset > the max cost. Both would require an extra field to be added to either the > rq or domain structure though. I think both ideas are good things to try; but I would like them to be follow-up patches. I'm not worried too much about growing either structures. The thing you 'forgot' to mention is if this patch actually helps you workload? -- 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/
