On 07/26/2013 08:29 PM, Rik van Riel wrote: > On 07/26/2013 02:27 PM, Arjan van de Ven wrote: >> On 7/26/2013 11:13 AM, Rik van Riel wrote: >> >>> >>> Could you try running the tests with just the repeat mode >>> stuff from commit 69a37bea excluded, but leaving the common >>> infrastructure and commit e11538? >>> >> >> personally I think we should go the other way around. >> revert the set entirely first, and now, and get our performance back >> to what it should be >> >> and then see what we can add back without causing the regressions. >> this may take longer, or be done in steps, and that's ok. >> >> the end point may well be the same... but we can then evaluate in the >> right >> direction. > > Works for me. I have no objection to reverting both patches, > if the people planning to fix the code prefer that :)
I am favor of reverting these patches also because they don't solve the root problem of reducing the prediction failure. The menu governor tries to deduce the next wakeup but based on events per cpu. That means if a task with a specific behavior is migrated across cpus, the statistics will be wrong. IMHO, the menu governor has too much heuristic in there and may be we should consider the scheduler to pass more informations to the governor and remove some of these heuristics. Beside that, on ARM the cpus could be coupled and the timer to detect the prediction will wake up the entire cluster, making the power saving less efficient and impacting the statistics of the other cpu. -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- 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/
