{"push_id":860620905,"size":3,"distinct_size":3,"ref":"refs/heads/m","head":"18fe1f14bbadf7d68d07400c82c1b003f6f8f99f","before":"fa1b5925df0a7372b1b7064b6e2560904bb173f4","commits":[{"sha":"3f99185d4c6a7a0c2a980de167b63b3531a598a3","author":{"email":"c9df6394cb541f693236245820fbe23866f1a3fe@linux-m68k.org","name":"Andreas Schwab"},"message":"cpufreq: Fix wrong time unit conversion\n\ncommit a857c0b9e24e39fe5be82451b65377795f9538d8 upstream.\n\nThe time spent by a CPU under a given frequency is stored in jiffies unit\nin the cpu var cpufreq_stats_table->time_in_state[i], i being the index of\nthe frequency.\n\nThis is what is displayed in the following file on the right column:\n\n     cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state\n     2301000 19835820\n     2300000 3172\n     [...]\n\nNow cpufreq converts this jiffies unit delta to clock_t before returning it\nto the user as in the above file. And that conversion is achieved using the API\ncputime64_to_clock_t().\n\nAlthough it accidentally works on traditional tick based cputime accounting, where\ncputime_t maps directly to jiffies, it doesn't work with other types of cputime\naccounting such as CONFIG_VIRT_CPU_ACCOUNTING_* where cputime_t can map to nsecs\nor any granularity preffered by the architecture.\n\nFor example we get a buggy zero delta on full dyntick configurations:\n\n     cat /sys/devices/system/cpu/cpuX/cpufreq/stats/time_in_state\n     2301000 0\n     2300000 0\n     [...]\n\nFix this with using the proper jiffies_64_t to clock_t conversion.\n\nReported-and-tested-by: Carsten Emde <C.Emde@osadl.org>\nSigned-off-by: Andreas Schwab <schwab@linux-m68k.org>\nSigned-off-by: Frederic Weisbecker <fweisbec@gmail.com>\nAcked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nCc: Mark Brown <broonie@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/gchild320/flounder/commits/3f99185d4c6a7a0c2a980de167b63b3531a598a3"},{"sha":"9da02474bf3b95f251a11e393ce992d84b4ad17e","author":{"email":"7d26b35203412f18a7dea4f8e1db1a75b1c5b706@semaphore.gr","name":"Stratos Karafotis"},"message":"cpufreq: ondemand: Change the calculation of target frequency\n\ncommit dfa5bb622555d9da0df21b50f46ebdeef390041b upstream.\n\nThe ondemand governor calculates load in terms of frequency and\nincreases it only if load_freq is greater than up_threshold\nmultiplied by the current or average frequency.  This appears to\nproduce oscillations of frequency between min and max because,\nfor example, a relatively small load can easily saturate minimum\nfrequency and lead the CPU to the max.  Then, it will decrease\nback to the min due to small load_freq.\n\nChange the calculation method of load and target frequency on the\nbasis of the following two observations:\n\n - Load computation should not depend on the current or average\n   measured frequency.  For example, absolute load of 80% at 100MHz\n   is not necessarily equivalent to 8% at 1000MHz in the next\n   sampling interval.\n\n - It should be possible to increase the target frequency to any\n   value present in the frequency table proportional to the absolute\n   load, rather than to the max only, so that:\n\n   Target frequency = C * load\n\n   where we take C = policy->cpuinfo.max_freq / 100.\n\nTested on Intel i7-3770 CPU @ 3.40GHz and on Quad core 1500MHz Krait.\nPhoronix benchmark of Linux Kernel Compilation 3.1 test shows an\nincrease ~1.5% in performance. cpufreq_stats (time_in_state) shows\nthat middle frequencies are used more, with this patch.  Highest\nand lowest frequencies were used less by ~9%.\n\n[rjw: We have run multiple other tests on kernels with this\n change applied and in the vast majority of cases it turns out\n that the resulting performance improvement also leads to reduced\n consumption of energy.  The change is additionally justified by\n the overall simplification of the code in question.]\n\nSigned-off-by: Stratos Karafotis <stratosk@semaphore.gr>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nCc: Mark Brown <broonie@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/gchild320/flounder/commits/9da02474bf3b95f251a11e393ce992d84b4ad17e"},{"sha":"18fe1f14bbadf7d68d07400c82c1b003f6f8f99f","author":{"email":"4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","name":"Greg Kroah-Hartman"},"message":"Linux 3.10.57","distinct":true,"url":"https://api.github.com/repos/gchild320/flounder/commits/18fe1f14bbadf7d68d07400c82c1b003f6f8f99f"}]}