{"push_id":920237670,"size":7,"distinct_size":7,"ref":"refs/heads/SkyHigh","head":"c1905df602db2c91bc2b755de6617fa3af5ec6aa","before":"b13a9504a3678564c5772506e939baeafd2c4fc3","commits":[{"sha":"3b7d5a76f2dd199a13dc5f2bbc1cb1dd183458a0","author":{"email":"5b23f8226e886b22344fc642373ea657dd596b63@linux.vnet.ibm.com","name":"Srivatsa S. Bhat"},"message":"cpufreq: governor: Be friendly towards latency-sensitive bursty workloads\n\nCpufreq governors like the ondemand governor calculate the load on the CPU\nperiodically by employing deferrable timers. A deferrable timer won't fire\nif the CPU is completely idle (and there are no other timers to be run), in\norder to avoid unnecessary wakeups and thus save CPU power.\n\nHowever, the load calculation logic is agnostic to all this, and this can\nlead to the problem described below.\n\nTime (ms)               CPU 1\n\n100                Task-A running\n\n110                Governor's timer fires, finds load as 100% in the last\n                   10ms interval and increases the CPU frequency.\n\n110.5              Task-A running\n\n120\t\t   Governor's timer fires, finds load as 100% in the last\n\t\t   10ms interval and increases the CPU frequency.\n\n125\t\t   Task-A went to sleep. With nothing else to do, CPU 1\n\t\t   went completely idle.\n\n200\t\t   Task-A woke up and started running again.\n\n200.5\t\t   Governor's deferred timer (which was originally programmed\n\t\t   to fire at time 130) fires now. It calculates load for the\n\t\t   time period 120 to 200.5, and finds the load is almost zero.\n\t\t   Hence it decreases the CPU frequency to the minimum.\n\n210\t\t   Governor's timer fires, finds load as 100% in the last\n\t\t   10ms interval and increases the CPU frequency.\n\nSo, after the workload woke up and started running, the frequency was suddenly\ndropped to absolute minimum, and after that, there was an unnecessary delay of\n10ms (sampling period) to increase the CPU frequency back to a reasonable value.\nAnd this pattern repeats for every wake-up-from-cpu-idle for that workload.\nThis can be quite undesirable for latency- or response-time sensitive bursty\nworkloads. So we need to fix the governor's logic to detect such wake-up-from-\ncpu-idle scenarios and start the workload at a reasonably high CPU frequency.\n\nOne extreme solution would be to fake a load of 100% in such scenarios. But\nthat might lead to undesirable side-effects such as frequency spikes (which\nmight also need voltage changes) especially if the previous frequency happened\nto be very low.\n\nWe just want to avoid the stupidity of dropping down the frequency to a minimum\nand then enduring a needless (and long) delay before ramping it up back again.\nSo, let us simply carry forward the previous load - that is, let us just pretend\nthat the 'load' for the current time-window is the same as the load for the\nprevious window. That way, the frequency and voltage will continue to be set\nto whatever values they were set at previously. This means that bursty workloads\nwill get a chance to influence the CPU frequency at which they wake up from\ncpu-idle, based on their past execution history. Thus, they might be able to\navoid suffering from slow wakeups and long response-times.\n\nHowever, we should take care not to over-do this. For example, such a \"copy\nprevious load\" logic will benefit cases like this: (where # represents busy\nand . represents idle)\n\n##########.........#########.........###########...........##########........\n\nbut it will be detrimental in cases like the one shown below, because it will\nretain the high frequency (copied from the previous interval) even in a mostly\nidle system:\n\n##########.........#.................#.....................#...............\n\n(i.e., the workload finished and the remaining tasks are such that their busy\nperiods are smaller than the sampling interval, which causes the timer to\nalways get deferred. So, this will make the copy-previous-load logic copy\nthe initial high load to subsequent idle periods over and over again, thus\nkeeping the frequency high unnecessarily).\n\nSo, we modify this copy-previous-load logic such that it is used only once\nupon every wakeup-from-idle. Thus if we have 2 consecutive idle periods, the\nprevious load won't get blindly copied over; cpufreq will freshly evaluate the\nload in the second idle interval, thus ensuring that the system comes back to\nits normal state.\n\n[ The right way to solve this whole problem is to teach the CPU frequency\ngovernors to also track load on a per-task basis, not just a per-CPU basis,\nand then use both the data sources intelligently to set the appropriate\nfrequency on the CPUs. But that involves redesigning the cpufreq subsystem,\nso this patch should make the situation bearable until then. ]\n\nExperimental results:\n+-------------------+\n\nI ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in\nbetween its execution such that its total utilization can be a user-defined\nvalue, say 10% or 20% (higher the utilization specified, lesser the amount of\nsleeps injected). This ebizzy was run with a single-thread, tied to CPU 8.\n\nBehavior observed with tracing (sample taken from 40% utilization runs):\n------------------------------------------------------------------------\n\nWithout patch:\n~~~~~~~~~~~~~~\nkworker/8:2-12137  416.335742: cpu_frequency: state=2061000 cpu_id=8\nkworker/8:2-12137  416.335744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.345741: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.345744: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-12137  416.345746: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.355738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n<snip>  ---------------------------------------------------------------------  <snip>\n      <...>-40753  416.402202: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8\n     <idle>-0      416.502130: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy\n      <...>-40753  416.505738: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.505739: cpu_frequency: state=2061000 cpu_id=8\nkworker/8:2-12137  416.505741: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40753  416.515739: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-12137  416.515742: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-12137  416.515744: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n\nObservation: Ebizzy went idle at 416.402202, and started running again at\n416.502130. But cpufreq noticed the long idle period, and dropped the frequency\nat 416.505739, only to increase it back again at 416.515742, realizing that the\nworkload is in-fact CPU bound. Thus ebizzy needlessly ran at the lowest frequency\nfor almost 13 milliseconds (almost 1 full sample period), and this pattern\nrepeats on every sleep-wakeup. This could hurt latency-sensitive workloads quite\na lot.\n\nWith patch:\n~~~~~~~~~~~\n\nkworker/8:2-29802  464.832535: cpu_frequency: state=2061000 cpu_id=8\n<snip>  ---------------------------------------------------------------------  <snip>\nkworker/8:2-29802  464.962538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  464.972533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  464.972536: cpu_frequency: state=4123000 cpu_id=8\nkworker/8:2-29802  464.972538: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  464.982531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n<snip>  ---------------------------------------------------------------------  <snip>\nkworker/8:2-29802  465.022533: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.032531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  465.032532: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.035797: sched_switch: prev_comm=ebizzy ==> next_comm=swapper/8\n     <idle>-0      465.240178: sched_switch: prev_comm=swapper/8 ==> next_comm=ebizzy\n      <...>-40738  465.242533: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\nkworker/8:2-29802  465.242535: sched_switch: prev_comm=kworker/8:2 ==> next_comm=ebizzy\n      <...>-40738  465.252531: sched_switch: prev_comm=ebizzy ==> next_comm=kworker/8:2\n\nObservation: Ebizzy went idle at 465.035797, and started running again at\n465.240178. Since ebizzy was the only real workload running on this CPU,\ncpufreq retained the frequency at 4.1Ghz throughout the run of ebizzy, no\nmatter how many times ebizzy slept and woke-up in-between. Thus, ebizzy\ngot the 10ms worth of 4.1 Ghz benefit during every sleep-wakeup (as compared\nto the run without the patch) and this boost gave a modest improvement in total\nthroughput, as shown below.\n\nSleeping-ebizzy records-per-second:\n-----------------------------------\n\nUtilization  Without patch  With patch  Difference (Absolute and % values)\n    10%         274767        277046        +  2279 (+0.829%)\n    20%         543429        553484        + 10055 (+1.850%)\n    40%        1090744       1107959        + 17215 (+1.578%)\n    60%        1634908       1662018        + 27110 (+1.658%)\n\nA rudimentary and somewhat approximately latency-sensitive workload such as\nsleeping-ebizzy itself showed a consistent, noticeable performance improvement\nwith this patch. Hence, workloads that are truly latency-sensitive will benefit\nquite a bit from this change. Moreover, this is an overall win-win since this\npatch does not hurt power-savings at all (because, this patch does not reduce\nthe idle time or idle residency; and the high frequency of the CPU when it goes\nto cpu-idle does not affect/hurt the power-savings of deep idle states).\n\nSigned-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nReviewed-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/3b7d5a76f2dd199a13dc5f2bbc1cb1dd183458a0"},{"sha":"a1982c409c8b854fc2fe1e66da6636e3d53636d7","author":{"email":"5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","name":"Viresh Kumar"},"message":"cpufreq: governor: remove copy_prev_load from 'struct cpu_dbs_common_info'\n\n'copy_prev_load' was recently added by commit: 18b46ab (cpufreq: governor: Be\nfriendly towards latency-sensitive bursty workloads).\n\nIt actually is a bit redundant as we also have 'prev_load' which can store any\ninteger value and can be used instead of 'copy_prev_load' by setting it zero.\n\nTrue load can also turn out to be zero during long idle intervals (and hence the\nactual value of 'prev_load' and the overloaded value can clash). However this is\nnot a problem because, if the true load was really zero in the previous\ninterval, it makes sense to evaluate the load afresh for the current interval\nrather than copying the previous load.\n\nSo, drop 'copy_prev_load' and use 'prev_load' instead.\n\nUpdate comments as well to make it more clear.\n\nThere is another change here which was probably missed by Srivatsa during the\nlast version of updates he made. The unlikely in the 'if' statement was covering\nonly half of the condition and the whole line should actually come under it.\n\nAlso checkpatch is made more silent as it was reporting this (--strict option):\n\nCHECK: Alignment should match open parenthesis\n+\t\tif (unlikely(wall_time > (2 * sampling_rate) &&\n+\t\t\t\t\t\tj_cdbs->prev_load)) {\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nReviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nAcked-by: Pavel Machek <pavel@ucw.cz>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/a1982c409c8b854fc2fe1e66da6636e3d53636d7"},{"sha":"bf4f84e86aca5e426070379185e3774b4ae45311","author":{"email":"09ebf12aa4fd61769490ade56a7655bcf429b765@hp.com","name":"Jason Low"},"message":"sched: Reduce overestimating rq->avg_idle\n\nWhen updating avg_idle, if the delta exceeds some max value, then avg_idle\ngets set to the max, regardless of what the previous avg was. This can cause\navg_idle to often be overestimated.\n\nThis patch modifies the way we update avg_idle by always updating it with the\nfunction call to update_avg() first. Then, if avg_idle exceeds the max, we set\nit to the max.\n\nSigned-off-by: Jason Low <jason.low2@hp.com>\nReviewed-by: Rik van Riel <riel@redhat.com>\nReviewed-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1379096813-3032-2-git-send-email-jason.low2@hp.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/bf4f84e86aca5e426070379185e3774b4ae45311"},{"sha":"4925d494448a7d3225459f8567779811abb80bdf","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"mm: per-thread vma caching\n\nThis patch is a continuation of efforts trying to optimize find_vma(),\navoiding potentially expensive rbtree walks to locate a vma upon faults.\nThe original approach (https://lkml.org/lkml/2013/11/1/410), where the\nlargest vma was also cached, ended up being too specific and random,\nthus further comparison with other approaches were needed.  There are\ntwo things to consider when dealing with this, the cache hit rate and\nthe latency of find_vma().  Improving the hit-rate does not necessarily\ntranslate in finding the vma any faster, as the overhead of any fancy\ncaching schemes can be too high to consider.\n\nWe currently cache the last used vma for the whole address space, which\nprovides a nice optimization, reducing the total cycles in find_vma() by\nup to 250%, for workloads with good locality.  On the other hand, this\nsimple scheme is pretty much useless for workloads with poor locality.\nAnalyzing ebizzy runs shows that, no matter how many threads are\nrunning, the mmap_cache hit rate is less than 2%, and in many situations\nbelow 1%.\n\nThe proposed approach is to replace this scheme with a small per-thread\ncache, maximizing hit rates at a very low maintenance cost.\nInvalidations are performed by simply bumping up a 32-bit sequence\nnumber.  The only expensive operation is in the rare case of a seq\nnumber overflow, where all caches that share the same address space are\nflushed.  Upon a miss, the proposed replacement policy is based on the\npage number that contains the virtual address in question.  Concretely,\nthe following results are seen on an 80 core, 8 socket x86-64 box:\n\n1) System bootup: Most programs are single threaded, so the per-thread\n   scheme does improve ~50% hit rate by just adding a few more slots to\n   the cache.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 50.61%   | 19.90            |\n| patched        | 73.45%   | 13.58            |\n+----------------+----------+------------------+\n\n2) Kernel build: This one is already pretty good with the current\n   approach as we're dealing with good locality.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 75.28%   | 11.03            |\n| patched        | 88.09%   | 9.31             |\n+----------------+----------+------------------+\n\n3) Oracle 11g Data Mining (4k pages): Similar to the kernel build workload.\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 70.66%   | 17.14            |\n| patched        | 91.15%   | 12.57            |\n+----------------+----------+------------------+\n\n4) Ebizzy: There's a fair amount of variation from run to run, but this\n   approach always shows nearly perfect hit rates, while baseline is just\n   about non-existent.  The amounts of cycles can fluctuate between\n   anywhere from ~60 to ~116 for the baseline scheme, but this approach\n   reduces it considerably.  For instance, with 80 threads:\n\n+----------------+----------+------------------+\n| caching scheme | hit-rate | cycles (billion) |\n+----------------+----------+------------------+\n| baseline       | 1.06%    | 91.54            |\n| patched        | 99.97%   | 14.18            |\n+----------------+----------+------------------+\n\n[akpm@linux-foundation.org: fix nommu build, per Davidlohr]\n[akpm@linux-foundation.org: document vmacache_valid() logic]\n[akpm@linux-foundation.org: attempt to untangle header files]\n[akpm@linux-foundation.org: add vmacache_find() BUG_ON]\n[hughd@google.com: add vmacache_valid_mm() (from Oleg)]\n[akpm@linux-foundation.org: coding-style fixes]\n[akpm@linux-foundation.org: adjust and enhance comments]\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nReviewed-by: Rik van Riel <riel@redhat.com>\nAcked-by: Linus Torvalds <torvalds@linux-foundation.org>\nReviewed-by: Michel Lespinasse <walken@google.com>\nCc: Oleg Nesterov <oleg@redhat.com>\nTested-by: Hugh Dickins <hughd@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tkernel/fork.c\n\tmm/Makefile\n\tmm/mmap.c\n\nSigned-off-by: UpInTheAir <upintheair.xda@gmail.com>\nConflicts:\n\tmm/Makefile","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/4925d494448a7d3225459f8567779811abb80bdf"},{"sha":"9220432571f46d71a5e1ec054f4a80957161451c","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"mm,vmacache: optimize overflow system-wide flushing\n\nFor single threaded workloads, we can avoid flushing and iterating through\nthe entire list of tasks, making the whole function a lot faster,\nrequiring only a single atomic read for the mm_users.\n\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nSuggested-by: Oleg Nesterov <oleg@redhat.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/9220432571f46d71a5e1ec054f4a80957161451c"},{"sha":"80ba104773b0055206223bba59d99d54dc08ffc7","author":{"email":"96c56e33d93d5f83686c7a552b3f4f5937152d38@gmail.com","name":"UpInTheAir"},"message":"Revert \"mm,vmacache: optimize overflow system-wide flushing\"\n\nThis reverts commit 9220432571f46d71a5e1ec054f4a80957161451c.","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/80ba104773b0055206223bba59d99d54dc08ffc7"},{"sha":"c1905df602db2c91bc2b755de6617fa3af5ec6aa","author":{"email":"96c56e33d93d5f83686c7a552b3f4f5937152d38@gmail.com","name":"UpInTheAir"},"message":"Revert \"mm: per-thread vma caching\"\n\nThis reverts commit 4925d494448a7d3225459f8567779811abb80bdf.","distinct":true,"url":"https://api.github.com/repos/UpInTheAir/SM-N920/commits/c1905df602db2c91bc2b755de6617fa3af5ec6aa"}]}