On 2014.06.11 14:45 Rafael J. Wysocki wrote: > On Wed, Jun 11, 2014 at 11:40 PM, Doug Smythies <dsmyth...@telus.net> wrote: > >> Myself, I consider the issue of excessive deferred timer times to be a much >> higher priority (see my on-list e-mail from Monday). Correct me if I am >> wrong. >> Even without the "excessive" part, and for a 250 Hz kernel, the current kick >> in point can be hit routinely, unduly biasing the CPU frequency downwards. >> A random example (250 Hz kernel): 23% load at 25 Hertz load / sleep >> frequency for 300 total seconds. >> >> Duration histrogram: >> >> Occurrences duration (seconds) >> 16 0.044 >> 39 0.024 >> 45 0.028 >> 46 0.016 >> 48 0.032 >> 61 0.036 >> 166 0.012 >> 198 0.020 >> 7166 0.040 >> >> Where you can see that the majority of the time the duration is such that >> the code will force the CPU frequency downwards. >> It runs at minimum pstate instead of maximum pstate where it should be.
> I see. > What would you suggest to do to address this problem, then? The above specific example can be solved by increasing the kick in factor from "sample_rate * 3" to something more. As mentioned in my e-mail of Monday, I do not know how to proceed further with investigating the excessive deferral issue. There are some ideas (I think originally from Dirk) that wouldn't involve "[PATCH 3/4] intel_pstate: add sample time scaling" at all, but so far they have had issues also. There is something I would like to try, but it will take at least a few days. ... Doug -- 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/
