{"push_id":1436709266,"size":31,"distinct_size":31,"ref":"refs/heads/master","head":"55d854043ada508f0955c25433d3f922cda39eeb","before":"b5764e1031ccae8aadb242ad84265071ed4046e7","commits":[{"sha":"8ad01e1462a6fc55b276b785fd8b50ea7f5a598a","author":{"name":"Noxxx","email":"f1d9dce37f258e1f51cd12aa10899fab40433275@hotmail.com"},"message":"Interactive: Screen off 1ghz max\nCredits: imoseyon","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/8ad01e1462a6fc55b276b785fd8b50ea7f5a598a"},{"sha":"bec322e640bcb24408a3c91778650bfcbc7e2c82","author":{"name":"yank555-lu","email":"4ef8a2555692077f234eb620510f1de72b709988@gmail.com"},"message":"kernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.5 (faux123/Yank555.lu)\n\npowersuspend: new PM kernel driver for Android w/o early_suspend\n\nAndroid early_suspend/late_resume PM kernel driver framework has been\ndeprecated by Google. This new powersuspend PM kernel driver is a replacement\nfor it and existing early_suspend drivers can be easily adapted to use this\nnew replacement driver\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\npowersuspend: fix logci derps :p\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nkernel/power/powersuspend: remove userspace dependency from powersuspend\n\nmake powersuspend not depend on a userspace initiator anymore, but use a hook\nin autosleep instead.\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nkernel/power/powersuspend: add back userpace control w/ default kernel control\n\nmake kernel / userspace mode switchable\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nkernel/power/powersuspend: default to userspace for now\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nkernel/power/powersuspend: LCD screen on/off hooks (Yank555.lu)\n\n- add an alternative hook for screen on / off detection in the display\n  pannel driver\n- sleeps  ~0.1s sooner, wakes up ~1s later then autosleep\n- clean up source formatting a bit (Paul Reioux)\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nmdss_dsi_panel.c: add powersuspend hooks\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nkernel/power/powersuspend: cumulative update to version 1.5\n\n- fix hybrid-kernel mode cannot be set through sysfs\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.4 (Yank555.lu)\n\n- add hybrid-kernel mode (autosleep and panel, first wins)\n- default to hybrid-kernel mode\n- harmonize debug message with my other stuff\n- include all 3 modes as default, so it's only commenting out to change\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.3 (Yank555.lu)\n\n- fix stupid typo\n- add an alternative hook for screen on / off detection in the display panel driver\n(sleeps ~0.1s sooner, wakes up ~1s later then autosleep)\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.2 (Yank555.lu)\n\n- make kernel / userspace mode switchable\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.1 (Yank555.lu)\n\n- make powersuspend not depend on a userspace initiator anymore, but use a hook in autosleep instead.\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend (faux123)\n\nAndroid early_suspend/late_resume PM kernel driver framework has been\ndeprecated by Google. This new powersuspend PM kernel driver is a replacement\nfor it and existing early_suspend drivers can be easily adapted to use this\nnew replacement driver\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\ndrivers/video/msm/mdss/mdss_dsi_panel.c: update powersuspend hook calls\n\nfix typo!\n\nChange-Id: If9ee91d5ff2ba2d7623865758d0d8cdf582c341c\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tdrivers/video/msm/mdss/mdss_dsi_panel.c\n\ndecon: add powersuspend hooks\n\nSigned-off-by: arter97 <qkrwngud825@gmail.com>\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.6 (faux123/Yank555.lu)\n\n- autosleep hook removed, not working on shamu\n- autosleep and hybrid modes removed\n- panel mode is now default\n- debug output switchable in defconfig\n\nChange-Id: I8932ec280cb6185e1866b8ed0d35e4156a1fb35e\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.7 (faux123/Yank555.lu)\n\n- do only run state change if change actually requests a new state\n\nChange-Id: I3f3989ce939cd4d60831fb05dc8790cf10bcbd17\n\nkernel/power/powersuspend: new PM kernel driver for Android w/o early_suspend v1.7 (faux123/Yank555.lu)\n\n- fix a #ifdef / #endif derp\n\nThanx to AuxXxilium (Christian Schulthess) for pointing this out to me !\n\nChange-Id: I5827ea36a69e4a42d6a9196749ccac12c8bee746\nSigned-off-by: yank555-lu <yank555.lu@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/bec322e640bcb24408a3c91778650bfcbc7e2c82"},{"sha":"ea41f8275f65e515b6243d8e54b29746eb41077a","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/Noxxxious/test/commits/ea41f8275f65e515b6243d8e54b29746eb41077a"},{"sha":"35a940ef128fc745d384738943572708c600bd60","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)\n\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%\n\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>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/35a940ef128fc745d384738943572708c600bd60"},{"sha":"a70a3678b2069709acfa739143660b9472f1dddb","author":{"name":"Peter Zijlstra","email":"4d3106856cce90e8f40acc5180f60ddda3a23b6e@infradead.org"},"message":"sched: Micro-optimize the smart wake-affine logic\n\nSmart wake-affine is using node-size as the factor currently, but the overhead\nof the mask operation is high.\n\nThus, this patch introduce the 'sd_llc_size' percpu variable, which will record\nthe highest cache-share domain size, and make it to be the new factor, in order\nto reduce the overhead and make it more reasonable.\n\nTested-by: Davidlohr Bueso <davidlohr.bueso@hp.com>\nTested-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nAcked-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nLink: http://lkml.kernel.org/r/51D5008E.6030102@linux.vnet.ibm.com\n[ Tidied up the changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/a70a3678b2069709acfa739143660b9472f1dddb"},{"sha":"415da38b81374df2ac6decb2f3aeb6bba1eb0b1f","author":{"name":"Vincent Guittot","email":"9a88ec82ddd651c42e4062b28722f0a8c298d7ae@linaro.org"},"message":"sched: Remove a wake_affine() condition\n\nIn wake_affine() I have tried to understand the meaning of the condition:\n\n (this_load <= load &&\n  this_load + target_load(prev_cpu, idx) <= tl_per_task)\n\nbut I failed to find a use case that can take advantage of it and I haven't\nfound clear description in the previous commit's log.\n\nFuthermore, the comment of the condition refers to the task_hot function that\nwas used before being replaced by the current condition:\n\n/*\n * This domain has SD_WAKE_AFFINE and\n * p is cache cold in this domain, and\n * there is no bad imbalance.\n */\n\nIf we look more deeply the below condition:\n\n this_load + target_load(prev_cpu, idx) <= tl_per_task\n\nWhen sync is clear, we have:\n\n tl_per_task = runnable_load_avg / nr_running\n this_load = max(runnable_load_avg, cpuload[idx])\n target_load =  max(runnable_load_avg', cpuload'[idx])\n\nIt implies that runnable_load_avg == 0 and nr_running <= 1 in order to match the\ncondition. This implies that runnable_load_avg == 0 too because of the\ncondition: this_load <= load.\n\nbut if this _load is null, 'balanced' is already set and the test is redundant.\n\nIf sync is set, it's not as straight forward as above (especially if cgroup\nare involved) but the policy should be similar as we have removed a task that's\ngoing to sleep in order to get a more accurate load and this_load values.\n\nThe current conclusion is that these additional condition don't give any benefit\nso we can remove them.\n\nSigned-off-by: Vincent Guittot <vincent.guittot@linaro.org>\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: preeti@linux.vnet.ibm.com\nCc: riel@redhat.com\nCc: Morten.Rasmussen@arm.com\nCc: efault@gmx.de\nCc: nicolas.pitre@linaro.org\nCc: daniel.lezcano@linaro.org\nCc: dietmar.eggemann@arm.com\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/r/1409051215-16788-3-git-send-email-vincent.guittot@linaro.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/415da38b81374df2ac6decb2f3aeb6bba1eb0b1f"},{"sha":"7a71a29efebe5ee58a5e4408c1d109d0d92ac1ec","author":{"name":"Andrei F","email":"4fbf5deca414f6370c3ed33a9122945225c666b2@gmail.com"},"message":"Revert \"Revert \"cpuidle: Quickly notice prediction failure for repeat mode\"\"\n\nThis reverts commit d201a0b94daa5d8f7126c81678ccc04f9215772a.\n\nConflicts:\n\tdrivers/cpuidle/governors/menu.c","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/7a71a29efebe5ee58a5e4408c1d109d0d92ac1ec"},{"sha":"a4cf8310cd713cf0f33cf670cf90aea2bdcb20f5","author":{"name":"Andrei F","email":"4fbf5deca414f6370c3ed33a9122945225c666b2@gmail.com"},"message":"Revert \"Revert \"cpuidle: Quickly notice prediction failure in general case\"\"\n\nThis reverts commit 657e142082bec684725383eccd54e4ace5a2c293.\n\nThis will likely to reduce performance, hence reverted from the upstream.\nBut since we're mobile, it seems that it's no big deal.\n\nSigned-off-by: Park Ju Hyung <qkrwngud825@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/a4cf8310cd713cf0f33cf670cf90aea2bdcb20f5"},{"sha":"d84ee3b43bbfd2fc98f93fe98fc1816eb1766281","author":{"name":"Andrei F","email":"4fbf5deca414f6370c3ed33a9122945225c666b2@gmail.com"},"message":"cpuidle: menu: Add permissions and optimize perfect C-state residency","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/d84ee3b43bbfd2fc98f93fe98fc1816eb1766281"},{"sha":"3b6fe2a5978c48ee07649285a82a881757e8234f","author":{"name":"Namjae Jeon","email":"cee0fb13a02a9f6df517d42af792ebb078f2bc1f@samsung.com"},"message":"writeback: fix writeback cache thrashing\n\nConsider Process A: huge I/O on sda\n        doing heavy write operation - dirty memory becomes more\n        than dirty_background_ratio\n        on HDD - flusher thread flush-8:0\n\nConsider Process B: small I/O on sdb\n        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec\n        on Flash device - flusher thread flush-8:16\n\nAs Process A is a heavy dirtier, dirty memory becomes more\nthan dirty_background_thresh. Due to this, below check becomes\ntrue(checking global_page_state in over_bground_thresh)\nfor all bdi devices(even for very small dirtied bdi - sdb):\n\nIn this case, even small cached data on 'sdb' is forced to flush\nand writeback cache thrashing happens.\n\nWhen we added debug prints inside above 'if' condition and ran\nabove Process A(heavy dirtier on bdi with flush-8:0) and\nProcess B(1024K frequent read/rewrite on bdi with flush-8:16)\nwe got below prints:\n\n[Test setup: ARM dual core CPU, 512 MB RAM]\n\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB\n\nAs mentioned in above log, when global dirty memory > global background_thresh\nsmall cached data is also forced to flush by flush-8:16.\nIf removing global background_thresh checking code, we can reduce cache\nthrashing of frequently used small data.\nAnd It will be great if we can reserve a portion of writeback cache using\nmin_ratio.\n\nAfter applying patch:\n$ echo 5 > /sys/block/sdb/bdi/min_ratio\n$ cat /sys/block/sdb/bdi/min_ratio\n5\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB\n\nAs mentioned in the above logs, once cache is reserved for Process B,\nand patch is applied there is less writeback cache thrashing on sdb\nby frequent forced writeback by flush-8:16 in over_bground_thresh.\n\nAfter all, small cached data will be flushed by periodic writeback\nonce every dirty_writeback_interval.\n\nSuggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nSigned-off-by: Namjae Jeon <namjae.jeon@samsung.com>\nSigned-off-by: Vivek Trivedi <t.vivek@samsung.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/3b6fe2a5978c48ee07649285a82a881757e8234f"},{"sha":"4e3d90a75b24ab921e54caea1dc0f3197657caf0","author":{"name":"ramgear","email":"f69620e59be9d495099daf98e24e66f83939f142@gmail.com"},"message":"int_sqrt.c: Correction square root algo with naming\n\nSigned-off-by: engstk <eng.stk@sapo.pt>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/4e3d90a75b24ab921e54caea1dc0f3197657caf0"},{"sha":"a5d0e5b6ec85fd9627d81e864df4b585cba89df5","author":{"name":"FlyFrog","email":"f69620e59be9d495099daf98e24e66f83939f142@gmail.com"},"message":"int_sqrt: Improve 3x faster integer sqrt.\n\nResult on 10,000,000 call.\nOld:\nsqrt(12345689) = 3513\nreal\t0m0.768s\nuser\t0m0.760s\nsys\t0m0.004s\n\nNew:\nsqrt(12345689) = 3513\nreal\t0m0.222s\nuser\t0m0.224s\nsys\t0m0.000s\n\nSigned-off-by: engstk <eng.stk@sapo.pt>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/a5d0e5b6ec85fd9627d81e864df4b585cba89df5"},{"sha":"cff118b8c0084a9d34c5da75f25c477689442bea","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/Noxxxious/test/commits/cff118b8c0084a9d34c5da75f25c477689442bea"},{"sha":"312bff7059e8cc6c940ba22f11382f8019400de8","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539\n\nThis AEAD uses a chacha20 ablkcipher and a poly1305 ahash to construct the\nChaCha20-Poly1305 AEAD as defined in RFC7539. It supports both synchronous and\nasynchronous operations, even if we currently have no async chacha20 or poly1305\ndrivers.\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/312bff7059e8cc6c940ba22f11382f8019400de8"},{"sha":"14f2d34def9c28cd0deb12289484f19d3d1f9a07","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: chacha20 - Add a generic ChaCha20 stream cipher implementation\n\nChaCha20 is a high speed 256-bit key size stream cipher algorithm designed by\nDaniel J. Bernstein. It is further specified in RFC7539 for use in IETF\nprotocols as a building block for the ChaCha20-Poly1305 AEAD.\n\nThis is a portable C implementation without any architecture specific\noptimizations. It uses a 16-byte IV, which includes the 12-byte ChaCha20 nonce\nprepended by the initial block counter. Some algorithms require an explicit\ncounter value, for example the mentioned AEAD construction.\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/14f2d34def9c28cd0deb12289484f19d3d1f9a07"},{"sha":"bfc18f14a552ca39afe4c6841da83983d9110f7d","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: poly1305 - Add a generic Poly1305 authenticator implementation\n\nPoly1305 is a fast message authenticator designed by Daniel J. Bernstein.\nIt is further defined in RFC7539 as a building block for the ChaCha20-Poly1305\nAEAD for use in IETF protocols.\n\nThis is a portable C implementation of the algorithm without architecture\nspecific optimizations, based on public domain code by Daniel J. Bernstein and\nAndrew Moon.\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/bfc18f14a552ca39afe4c6841da83983d9110f7d"},{"sha":"7946bc514497b3980fac279b6dcbb82b4019d284","author":{"name":"Herbert Xu","email":"b06c1e85ee1d40a691f7eaf317640579555a220e@gondor.apana.org.au"},"message":"crypto: aead - Add crypto_aead_set_reqsize helper\n\nThis patch adds the helper crypto_aead_set_reqsize so that people\ndon't have to directly access the aead internals to set the reqsize.\n\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/7946bc514497b3980fac279b6dcbb82b4019d284"},{"sha":"f322e46b43eba05e9bc2670ad046647265d521fa","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: chacha20 - Export common ChaCha20 helpers\n\nAs architecture specific drivers need a software fallback, export a\nChaCha20 en-/decryption function together with some helpers in a header\nfile.\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/f322e46b43eba05e9bc2670ad046647265d521fa"},{"sha":"388589b47e16125a4b3359add69207d379e403e3","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: testmgr - Add ChaCha20 test vectors from RFC7539\n\nWe explicitly set the Initial block Counter by prepending it to the nonce in\nLittle Endian. The same test vector is used for both encryption and decryption,\nChaCha20 is a cipher XORing a keystream.\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/388589b47e16125a4b3359add69207d379e403e3"},{"sha":"c66650df4f3e74c82031e498b702b41868267c07","author":{"name":"Martin Willi","email":"ea98e1d0a9a4d10e3af04e16be88050749615623@strongswan.org"},"message":"crypto: testmgr - Add Poly1305 test vectors from RFC7539\n\nSigned-off-by: Martin Willi <martin@strongswan.org>\nAcked-by: Steffen Klassert <steffen.klassert@secunet.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>","distinct":true,"url":"https://api.github.com/repos/Noxxxious/test/commits/c66650df4f3e74c82031e498b702b41868267c07"}]}
{"actor":{"display_login":"Noxxxious"}}