{"push_id":1142441288,"size":30,"distinct_size":30,"ref":"refs/heads/master","head":"4532ad52a95d8ba4f2d2dcadc7595b341f5962ef","before":"dfa5d84148945eabb74c9e36b6d05e2770d29f2d","commits":[{"sha":"887b3db4cdcc05811854698e181997e9fa484e65","author":{"name":"Tony Malagisi","email":"d829852177409cd62bc567f95707b3164b5db2d6@gmail.com"},"message":"Linux 3.10.61 to Linux 3.10.101","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/887b3db4cdcc05811854698e181997e9fa484e65"},{"sha":"b147f7f5f746b5c454cfa73360ea9436f9715e9a","author":{"name":"Srivatsa S. Bhat","email":"86fcb99d833c6028b7c159db19d83d69bb396a1e@linux.vnet.ibm.com"},"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/SM-G920P/Twisted-MM/commits/b147f7f5f746b5c454cfa73360ea9436f9715e9a"},{"sha":"fec98e9b44a486cdf2da4d809aa7e570da4040ea","author":{"name":"Michael Wang","email":"b16c88d7dfdd1ef5b39042b2a4824ece056cc8f9@linux.vnet.ibm.com"},"message":"sched: Implement smarter wake-affine logic\n\nThe wake-affine scheduler feature is currently always trying to pull\nthe wakee close to the waker. In theory this should be beneficial if\nthe waker's CPU caches hot data for the wakee, and it's also beneficial\nin the extreme ping-pong high context switch rate case.\n\nTesting shows it can benefit hackbench up to 15%.\n\nHowever, the feature is somewhat blind, from which some workloads\nsuch as pgbench suffer. It's also time-consuming algorithmically.\n\nTesting shows it can damage pgbench up to 50% - far more than the\nbenefit it brings in the best case.\n\nSo wake-affine should be smarter and it should realize when to\nstop its thankless effort at trying to find a suitable CPU to wake on.\n\nThis patch introduces 'wakee_flips', which will be increased each\ntime the task flips (switches) its wakee target.\n\nSo a high 'wakee_flips' value means the task has more than one\nwakee, and the bigger the number, the higher the wakeup frequency.\n\nNow when making the decision on whether to pull or not, pay attention to\nthe wakee with a high 'wakee_flips', pulling such a task may benefit\nthe wakee. Also imply that the waker will face cruel competition later,\nit could be very cruel or very fast depends on the story behind\n'wakee_flips', waker therefore suffers.\n\nFurthermore, if waker also has a high 'wakee_flips', that implies that\nmultiple tasks rely on it, then waker's higher latency will damage all\nof them, so pulling wakee seems to be a bad deal.\n\nThus, when 'waker->wakee_flips / wakee->wakee_flips' becomes\nhigher and higher, the cost of pulling seems to be worse and worse.\n\nThe patch therefore helps the wake-affine feature to stop its pulling\nwork when:\n\n\twakee->wakee_flips > factor &&\n\twaker->wakee_flips > (factor * wakee->wakee_flips)\nThe 'factor' here is the number of CPUs in the current CPU's NUMA node,\nso a bigger node will lead to more pulling since the trial becomes more\nsevere.\n\nAfter applying the patch, pgbench shows up to 40% improvements and no regressions.\n\nTested with 12 cpu x86 server and tip 3.10.0-rc7.\n\nThe percentages in the final column highlight the areas with the biggest wins,\nall other areas improved as well:\n\n\tpgbench\t\t    base\tsmart\n\n\t| db_size | clients |  tps  |\t|  tps  |\n\t+---------+---------+-------+   +-------+\n\t| 22 MB   |       1 | 10598 |   | 10796 |\n\t| 22 MB   |       2 | 21257 |   | 21336 |\n\t| 22 MB   |       4 | 41386 |   | 41622 |\n\t| 22 MB   |       8 | 51253 |   | 57932 |\n\t| 22 MB   |      12 | 48570 |   | 54000 |\n\t| 22 MB   |      16 | 46748 |   | 55982 | +19.75%\n\t| 22 MB   |      24 | 44346 |   | 55847 | +25.93%\n\t| 22 MB   |      32 | 43460 |   | 54614 | +25.66%\n\t| 7484 MB |       1 |  8951 |   |  9193 |\n\t| 7484 MB |       2 | 19233 |   | 19240 |\n\t| 7484 MB |       4 | 37239 |   | 37302 |\n\t| 7484 MB |       8 | 46087 |   | 50018 |\n\t| 7484 MB |      12 | 42054 |   | 48763 |\n\t| 7484 MB |      16 | 40765 |   | 51633 | +26.66%\n\t| 7484 MB |      24 | 37651 |   | 52377 | +39.11%\n\t| 7484 MB |      32 | 37056 |   | 51108 | +37.92%\n\t| 15 GB   |       1 |  8845 |   |  9104 |\n\t| 15 GB   |       2 | 19094 |   | 19162 |\n\t| 15 GB   |       4 | 36979 |   | 36983 |\n\t| 15 GB   |       8 | 46087 |   | 49977 |\n\t| 15 GB   |      12 | 41901 |   | 48591 |\n\t| 15 GB   |      16 | 40147 |   | 50651 | +26.16%\n\t| 15 GB   |      24 | 37250 |   | 52365 | +40.58%\n\t| 15 GB   |      32 | 36470 |   | 50015 | +37.14%\nSigned-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com\n[ Improved the changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/fec98e9b44a486cdf2da4d809aa7e570da4040ea"},{"sha":"29a81270ecce55d22553ed8d532f95e37c739065","author":{"name":"g.lewarne@gmx.co.uk","email":"7ba9bb6d1158f2c56536128edd9f1df9b8ff6d48@gmx.co.uk"},"message":"sched: micro optimise smart wake affine logic. original patch here https://github.com/faux123/Nexus_5/commit/91d9305ccc24566d598faf169cd8e9b7137f7b7f","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/29a81270ecce55d22553ed8d532f95e37c739065"},{"sha":"40426d5e15d7da2b7c470f9b5148c9bf652ca4bf","author":{"name":"Ganapatrao Kulkarni","email":"f6d91cab58ba06f381a0a1858f008d584e44eed2@caviumnetworks.com"},"message":"arm64: mm: update max pa bits to 48\n\nNow that we support 48-bit physical addressing, update MAX_PHYSMEM_BITS\naccordingly.\n\nAcked-by: Catalin Marinas <catalin.marinas@arm.com>\nSigned-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@caviumnetworks.com>\nSigned-off-by: Will Deacon <will.deacon@arm.com>\n(cherry picked from commit 07a15dd55a3d65f81b4b09eab293f4afc720b082)\nSigned-off-by: Mark Brown <broonie@kernel.org>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/40426d5e15d7da2b7c470f9b5148c9bf652ca4bf"},{"sha":"1c8ac24819dbfe9e727855308c3af90cace62f2e","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"tick: don't update idle time if cpu offline\n\nAn offline cpu still has ts->idle_active == 1, that cause\noff time is counted as idle time, and hence cause cpu load\ncalculated wrongly.\n\nCheck the cpu online status before updating the idle time to\nfix it.\n\nChange-Id: I00deb4cbcaec18f7625ee774bf4c3e643330dd5f\nSigned-off-by: Lianwei Wang <a22439@motorola.com>\nReviewed-on: http://gerrit.mot.com/695764\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Igor Kovalenko <igork@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n[picked from http://goo.gl/lLF51X]\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/1c8ac24819dbfe9e727855308c3af90cace62f2e"},{"sha":"78434555cf03b6a25b6de2a20e318153e20d8aca","author":{"name":"Srivatsa Vaddagiri","email":"4ebad9f61da157750c36beb638e9bb3384814e5d@codeaurora.org"},"message":"sched: Fix inaccurate accounting for real-time task\n\nIt is possible that rq->clock_task was not updated in put_prev_task()\nin which case we can potentially overcharge a real-time task for time\nit did not run. This is because clock_task could be stale and not\nrepresent the exact time real-time task started running.\n\nFix this by forcing update of rq->clock_task when real-time task\nstarts running.\n\nChange-Id: I8320bb4e47924368583127b950d987925e8e6a6c\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/78434555cf03b6a25b6de2a20e318153e20d8aca"},{"sha":"8cd5a5fcbba4eb62b6b179ea9775dc971fc8bcf3","author":{"name":"imoseyon","email":"10a51fa76245a6d62993b9f678997023cca4f98d@gmail.com"},"message":"fs/namei.c: fix potential memory leak in path_lookupat\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/8cd5a5fcbba4eb62b6b179ea9775dc971fc8bcf3"},{"sha":"cefc93bbf5b07c19b2d74394368b06c8d72728fc","author":{"name":"ktoonsez","email":"3e0e900edfc0ab91b66f60812ff46bba49154f87@gmail.com"},"message":"Add some info on boot for tables loads","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/cefc93bbf5b07c19b2d74394368b06c8d72728fc"},{"sha":"8d0e17a30cbac72c792e98b0927de4167d02e216","author":{"name":"ktoonsez","email":"3e0e900edfc0ab91b66f60812ff46bba49154f87@gmail.com"},"message":"Fix up CPU table for OC steps and increase MAX_VOLT","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/8d0e17a30cbac72c792e98b0927de4167d02e216"},{"sha":"833d614ecb03e09a8dfbb335cb7b71a8c1c6e2f1","author":{"name":"ktoonsez","email":"3e0e900edfc0ab91b66f60812ff46bba49154f87@gmail.com"},"message":"cpufreq: Add UC and OC steps for big and little CPU","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/833d614ecb03e09a8dfbb335cb7b71a8c1c6e2f1"},{"sha":"38596dd92324666b503946186e16f37ad7087569","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"tcp: we can enable tcp fast open functionality by default, apps such as Chrome are already using this feature, so we just need to enable it on the client side\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/38596dd92324666b503946186e16f37ad7087569"},{"sha":"519088729922b86eefe036520a8fee1d86effe15","author":{"name":"Alex Shi","email":"86471483ef45d8c07197ca74d2a2a81eaf9f0582@intel.com"},"message":"sched: Update cpu load after task_tick\n\nTo get the latest runnable info, we need do this cpuload update after\ntask_tick.\n\nSigned-off-by: Alex Shi <alex.shi@intel.com>\nReviewed-by: Paul Turner <pjt@google.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1371694737-29336-6-git-send-email-alex.shi@intel.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/519088729922b86eefe036520a8fee1d86effe15"},{"sha":"859b8c63dd014b1cc69c0d6614b9a1a0fbc8ab74","author":{"name":"Alex Shi","email":"86471483ef45d8c07197ca74d2a2a81eaf9f0582@intel.com"},"message":"sched: Consider runnable load average in move_tasks()\n\nAside from using runnable load average in background, move_tasks is\nalso the key function in load balance. We need consider the runnable\nload average in it in order to make it an apple to apple load\ncomparison.\n\nMorten had caught a div u64 bug on ARM, thanks!\n\nThanks-to: Morten Rasmussen <morten.rasmussen@arm.com>\nSigned-off-by: Alex Shi <alex.shi@intel.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1371694737-29336-8-git-send-email-alex.shi@intel.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/859b8c63dd014b1cc69c0d6614b9a1a0fbc8ab74"},{"sha":"ffa72f8dc040e8492972050d7fb108a3d5a86915","author":{"name":"Alex Shi","email":"86471483ef45d8c07197ca74d2a2a81eaf9f0582@intel.com"},"message":"sched: Change cfs_rq load avg to unsigned long\n\nSince the 'u64 runnable_load_avg, blocked_load_avg' in cfs_rq struct are\nsmaller than 'unsigned long' cfs_rq->load.weight. We don't need u64\nvaiables to describe them. unsigned long is more efficient and convenience.\n\nSigned-off-by: Alex Shi <alex.shi@intel.com>\nReviewed-by: Paul Turner <pjt@google.com>\nTested-by: Vincent Guittot <vincent.guittot@linaro.org>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1371694737-29336-10-git-send-email-alex.shi@intel.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/ffa72f8dc040e8492972050d7fb108a3d5a86915"},{"sha":"456d35cb383a61bd886c27a1d4fe198027d195ed","author":{"name":"Joonsoo Kim","email":"e700615c04bcea977d20418bded45c707d0cb497@lge.com"},"message":"sched: Remove one division operation in find_busiest_queue()\n\nRemove one division operation in find_busiest_queue() by using\ncrosswise multiplication:\n\n\twl_i / power_i > wl_j / power_j :=\n\twl_i * power_j > wl_j * power_i\n\nSigned-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>\n[ Expanded the changelog. ]\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1375778203-31343-2-git-send-email-iamjoonsoo.kim@lge.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/456d35cb383a61bd886c27a1d4fe198027d195ed"},{"sha":"b2a5fcf3e7bd992aa31e07fc1859e63e7a2980a6","author":{"name":"Peter Zijlstra","email":"4d3106856cce90e8f40acc5180f60ddda3a23b6e@infradead.org"},"message":"sched/fair: Optimize find_busiest_queue()\n\nUse for_each_cpu_and() and thereby avoid computing the capacity for\nCPUs we know we're not interested in.\n\nReviewed-by: Paul Turner <pjt@google.com>\nReviewed-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/n/tip-lppceyv6kb3a19g8spmrn20b@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/b2a5fcf3e7bd992aa31e07fc1859e63e7a2980a6"},{"sha":"1a2b531dfb0079a157b341d881b46da3a8e718d1","author":{"name":"franciscofranco","email":"0ac3193ff3d7b4e68ae404d59f776924e2be9ac9@gmail.com"},"message":"sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire. From http://ripke.com/loadavg/moire\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/1a2b531dfb0079a157b341d881b46da3a8e718d1"},{"sha":"1eb4fb9ea7fe282afe04909a14994aa2dfe72212","author":{"name":"Li Bin","email":"22b0b1264d7a67107b5064e55d2ce92d5086527b@huawei.com"},"message":"workqueue: fix pool ID allocation leakage and remove BUILD_BUG_ON() in init_workqueues\n\nWhen one work starts execution, the high bits of work's data contain\npool ID. It can represent a maximum of WORK_OFFQ_POOL_NONE. Pool ID\nis assigned WORK_OFFQ_POOL_NONE when the work being initialized\nindicating that no pool is associated and get_work_pool() uses it to\ncheck the associated pool. So if worker_pool_assign_id() assigns a\nID greater than or equal WORK_OFFQ_POOL_NONE to a pool, it triggers\nleakage, and it may break the non-reentrance guarantee.\n\nThis patch fix this issue by modifying the worker_pool_assign_id()\nfunction calling idr_alloc() by setting @end param WORK_OFFQ_POOL_NONE.\n\nFurthermore, in the current implementation, the BUILD_BUG_ON() in\ninit_workqueues makes no sense. The number of worker pools needed\ncannot be determined at compile time, because the number of backing\npools for UNBOUND workqueues is dynamic based on the assigned custom\nattributes. So remove it.\n\ntj: Minor comment and indentation updates.\n\nSigned-off-by: Li Bin <huawei.libin@huawei.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/1eb4fb9ea7fe282afe04909a14994aa2dfe72212"},{"sha":"edc3d84eaca02e46b8036467bba46948bdbbf6c7","author":{"name":"Thomas Gleixner","email":"352b5f5ba0189d2583768a9bb8247f98115b9038@linutronix.de"},"message":"workqueue: Provide destroy_delayed_work_on_stack()\n\nIf a delayed or deferrable work is on stack we need to tell debug\nobjects that we are destroying the timer and the work. Otherwise we\nleak the tracking object.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Vince Weaver <vincent.weaver@maine.edu>\nAcked-by: Tejun Heo <tj@kernel.org>\nLink: http://lkml.kernel.org/r/20140323141939.911487677@linutronix.de\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: XileForce <rdaguiar360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/SM-G920P/Twisted-MM/commits/edc3d84eaca02e46b8036467bba46948bdbbf6c7"}]}
{"actor":{"display_login":"SM-G920P"}}