{"push_id":1066765356,"size":36,"distinct_size":36,"ref":"refs/heads/m","head":"e5a5395d1bf54d52342d9715902c8042d5632c4f","before":"ccca173ed3c462befd0e0211b722da695905a816","commits":[{"sha":"e5b3a7d305ca394d5e040f8f68d0b7f24c90c999","author":{"email":"20b1b82ea87150022f6495522a9f5e355ea8b305@gmail.com","name":"Arianna Avanzini"},"message":"block: cgroups, kconfig, build bits for BFQ-v7r6-3.10.8+\n\nUpdate Kconfig.iosched and do the related Makefile changes to include\nkernel configuration options for BFQ. Also add the bfqio controller\nto the cgroups subsystem.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nChange-Id: Ieae0bfda9ff88fd42dbeaa275b4182517342e2f9","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/e5b3a7d305ca394d5e040f8f68d0b7f24c90c999"},{"sha":"90cc05b1179b36ae78542c75dae838c5d52a5b2d","author":{"email":"77843028b8f8419c9977951e271784ccf7804be9@unimore.it","name":"Paolo Valente"},"message":"block: introduce the BFQ-v7r6 I/O sched for 3.10.8+\n\nAdd the BFQ-v7r6 I/O scheduler to 3.10.8+.\nThe general structure is borrowed from CFQ, as much of the code for\nhandling I/O contexts Over time, several useful features have been\nported from CFQ as well (details in the changelog in README.BFQ). A\n(bfq_)queue is associated to each task doing I/O on a device, and each\ntime a scheduling decision has to be made a queue is selected and served\nuntil it expires.\n\n    - Slices are given in the service domain: tasks are assigned\n      budgets, measured in number of sectors. Once got the disk, a task\n      must however consume its assigned budget within a configurable\n      maximum time (by default, the maximum possible value of the\n      budgets is automatically computed to comply with this timeout).\n      This allows the desired latency vs \"throughput boosting\" tradeoff\n      to be set.\n\n    - Budgets are scheduled according to a variant of WF2Q+, implemented\n      using an augmented rb-tree to take eligibility into account while\n      preserving an O(log N) overall complexity.\n\n    - A low-latency tunable is provided; if enabled, both interactive\n      and soft real-time applications are guaranteed a very low latency.\n\n    - Latency guarantees are preserved also in the presence of NCQ.\n\n    - Also with flash-based devices, a high throughput is achieved\n      while still preserving latency guarantees.\n\n    - BFQ features Early Queue Merge (EQM), a sort of fusion of the\n      cooperating-queue-merging and the preemption mechanisms present\n      in CFQ. EQM is in fact a unified mechanism that tries to get a\n      sequential read pattern, and hence a high throughput, with any\n      set of processes performing interleaved I/O over a contiguous\n      sequence of sectors.\n\n    - BFQ supports full hierarchical scheduling, exporting a cgroups\n      interface.  Since each node has a full scheduler, each group can\n      be assigned its own weight.\n\n    - If the cgroups interface is not used, only I/O priorities can be\n      assigned to processes, with ioprio values mapped to weights\n      with the relation weight = IOPRIO_BE_NR - ioprio.\n\n    - ioprio classes are served in strict priority order, i.e., lower\n      priority queues are not served as long as there are higher\n      priority queues.  Among queues in the same class the bandwidth is\n      distributed in proportion to the weight of each queue. A very\n      thin extra bandwidth is however guaranteed to the Idle class, to\n      prevent it from starving.\n\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\n\nChange-Id: Ieae0bfda9ff88fd42dbeaa275b4182517342e2f0","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/90cc05b1179b36ae78542c75dae838c5d52a5b2d"},{"sha":"2be4b5d9532b3a32b91b2cb5fc662906ed00d7fd","author":{"email":"ddd3503978591997e768ebc37fca6c687c31d545@unimore.it","name":"Mauro Andreolini"},"message":"block, bfq: add Early Queue Merge (EQM) to BFQ-v7r6 for 3.10.8+\n\nA set of processes may happen  to  perform interleaved reads, i.e.,requests\nwhose union would give rise to a  sequential read  pattern.  There are two\ntypical  cases: in the first  case,   processes  read  fixed-size chunks of\ndata at a fixed distance from each other, while in the second case processes\nmay read variable-size chunks at  variable distances. The latter case occurs\nfor  example with  QEMU, which splits the  I/O generated  by the  guest into\nmultiple chunks,  and lets these chunks  be served by a  pool of cooperating\nprocesses,  iteratively  assigning  the  next  chunk of  I/O  to  the first\navailable  process. CFQ  uses actual  queue merging  for the  first type of\nrocesses, whereas it  uses preemption to get a sequential  read pattern out\nof the read requests  performed by the second type of  processes. In the end\nit uses  two different  mechanisms to  achieve the  same goal: boosting the\nthroughput with interleaved I/O.\n\nThis patch introduces  Early Queue Merge (EQM), a unified mechanism to get a\nsequential  read pattern  with both  types of  processes. The  main idea is\nchecking newly arrived requests against the next request of the active queue\nboth in case of actual request insert and in case of request merge. By doing\nso, both the types of processes can be handled by just merging their queues.\nEQM is  then simpler and  more compact than the  pair of mechanisms used in\nCFQ.\n\nFinally, EQM  also preserves the  typical low-latency properties of BFQ, by\nproperly restoring the weight-raising state of  a queue when it gets back to\na non-merged state.\n\nSigned-off-by: Mauro Andreolini <mauro.andreolini@unimore.it>\nSigned-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>\nSigned-off-by: Paolo Valente <paolo.valente@unimore.it>\n\nChange-Id: Ieae0bfda9ff88fd42dbeaa275b4182517342e2f1","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/2be4b5d9532b3a32b91b2cb5fc662906ed00d7fd"},{"sha":"7af7759d4f56bd9f9b3fda102f30324ba6620444","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\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(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>\n\nChange-Id: Ieae0bfda9ff88fd42dbeaa275b4182517342e2f3","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/7af7759d4f56bd9f9b3fda102f30324ba6620444"},{"sha":"69abd252aed65664d34d77bb8f5b013084864457","author":{"email":"00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","name":"Thomas Gleixner"},"message":"futex: Add another early deadlock detection check\n\ncommit 866293ee54227584ffcb4a42f69c1f365974ba7f upstream.\n\nDave Jones trinity syscall fuzzer exposed an issue in the deadlock\ndetection code of rtmutex:\n  http://lkml.kernel.org/r/20140429151655.GA14277@redhat.com\n\nThat underlying issue has been fixed with a patch to the rtmutex code,\nbut the futex code must not call into rtmutex in that case because\n    - it can detect that issue early\n    - it avoids a different and more complex fixup for backing out\n\nIf the user space variable got manipulated to 0x80000000 which means\nno lock holder, but the waiters bit set and an active pi_state in the\nkernel is found we can figure out the recursive locking issue by\nlooking at the pi_state owner. If that is the current task, then we\ncan safely return -EDEADLK.\n\nThe check should have been added in commit 59fa62451 (futex: Handle\nfutex_pi OWNER_DIED take over correctly) already, but I did not see\nthe above issue caused by user space manipulation back then.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Dave Jones <davej@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Darren Hart <darren@dvhart.com>\nCc: Davidlohr Bueso <davidlohr@hp.com>\nCc: Steven Rostedt <rostedt@goodmis.org>\nCc: Clark Williams <williams@redhat.com>\nCc: Paul McKenney <paulmck@linux.vnet.ibm.com>\nCc: Lai Jiangshan <laijs@cn.fujitsu.com>\nCc: Roland McGrath <roland@hack.frob.com>\nCc: Carlos ODonell <carlos@redhat.com>\nCc: Jakub Jelinek <jakub@redhat.com>\nCc: Michael Kerrisk <mtk.manpages@gmail.com>\nCc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>\nLink: http://lkml.kernel.org/r/20140512201701.097349971@linutronix.de\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n\nConflicts:\n\tkernel/futex.c\n\nChange-Id: Iee5dc11c39019eef9707d47c20d952f65ff41ad6","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/69abd252aed65664d34d77bb8f5b013084864457"},{"sha":"e3fa67487dc90e01ee3822bf6dc0d77504b557d8","author":{"email":"742cc7da48fa788d384ec77ccfb9a4657661404c@gmail.com","name":"imoseyon"},"message":"perf: remove duplicate call when removing per cpu events\n\n* derp, adcd5a5 forgot to remove it - could be bad if left in there\n\nChange-Id: Iee5dc11c39019eef9707d47c20d952f65ff41ad7","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/e3fa67487dc90e01ee3822bf6dc0d77504b557d8"},{"sha":"e904f34fd26080afe0dbd4dafe22f610ef1acd74","author":{"email":"168fbe9b48536378ad61dccedb637b5a226976e8@linux.org.tw","name":"Chih-Wei Huang"},"message":"cpufreq: interactive: fix compiling warnings\n\nThe gcc warns like:\n\n  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be undefined [-Wsequence-point]\n\nIt was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.\n\nSince sprintf(...) just return 1 (one character) in this case, ret should not changed.\nJust discarding the result of sprintf(...) leads to the result that\nthe committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.\n\nChange-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57\nSigned-off-by: Chih-Wei Huang <cwhuang@android-x86.org>\n\nConflicts:\n\tdrivers/cpufreq/cpufreq_interactive.c\n\nChange-Id: Iee5dc11c39019eef9707d47c20d952f65ff41ad9","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/e904f34fd26080afe0dbd4dafe22f610ef1acd74"},{"sha":"e47bc18db5b0707a5109df5bfdf38a9ee4653865","author":{"email":"4b3f23b045e38e54cffd83d34440316666b35af9@codeaurora.org","name":"Stepan Moskovchenko"},"message":"ARM: Use -mcpu=cortex-a15 when targeting MSM Krait CPUs\n\nEnable compiler optimizations specific to the Cortex-A15\nprocessor when targeting MSM Krait CPUs. This is necessary\ntake advantage of the UDIV/SDIV instructions supported by\nthese processors. To accomplish this, we need to remove the\n-march=armv7-a ISA restriction from the compiler options\nbecause 'cortex-a15' is a superset of 'armv7-a'.\n\nSigned-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: I6215aecc11fb4f77c971de7b84f68649ef234357","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/e47bc18db5b0707a5109df5bfdf38a9ee4653865"},{"sha":"4f67592cf527bf836eb258424374672cdebbc076","author":{"email":"d7fac3f7b328449401fe64671e732ac315caee28@cn.fujitsu.com","name":"Miao Xie"},"message":"lib/string: use glibc version\n\nthe performance of memcpy and memmove of the general version is very\ninefficient, this patch improved them.\n\nSigned-off-by: Miao Xie <miaox*******>\n\nConflicts:\n\n\tlib/string.c\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: I6215aecc11fb4f77c971de7b84f68649ef234358","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/4f67592cf527bf836eb258424374672cdebbc076"},{"sha":"33b238945b57ac96ccf1d2e0f450b890beff055d","author":{"email":"d7fac3f7b328449401fe64671e732ac315caee28@cn.fujitsu.com","name":"Miao Xie"},"message":"lib/memcopy: use glibc version\n\nthe kernel's memcpy and memmove is very inefficient. But the glibc version is\nquite fast, in some cases it is 10 times faster than the kernel version. So I\nintroduce some memory copy macros and functions of the glibc to improve the\nkernel version's performance.\n\nThe strategy of the memory functions is:\n1. Copy bytes until the destination pointer is aligned.\n2. Copy words in unrolled loops.  If the source and destination are not\n   aligned in the same way, use word memory operations, but shift and merge\n   two read words before writing.\n3. Copy the few remaining bytes.\n\nSigned-off-by: Miao Xie <miaox*******>\n\nConflicts:\n\n\tlib/Makefile\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: I6215aecc11fb4f77c971de7b84f68649ef234359","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/33b238945b57ac96ccf1d2e0f450b890beff055d"},{"sha":"0353e77a5c7057cbd6c96f527fe230c8a8274e21","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"sync: don't block the flusher thread waiting on IO\n\nWhen sync does it's WB_SYNC_ALL writeback, it issues data Io and\nthen immediately waits for IO completion. This is done in the\ncontext of the flusher thread, and hence completely ties up the\nflusher thread for the backing device until all the dirty inodes\nhave been synced. On filesystems that are dirtying inodes constantly\nand quickly, this means the flusher thread can be tied up for\nminutes per sync call and hence badly affect system level write IO\nperformance as the page cache cannot be cleaned quickly.\n\nWe already have a wait loop for IO completion for sync(2), so cut\nthis out of the flusher thread and delegate it to wait_sb_inodes().\nHence we can do rapid IO submission, and then wait for it all to\ncomplete.\n\nEffect of sync on fsmark before the patch:\n\nFSUse%        Count         Size    Files/sec     App Overhead\n.....\n     0       640000         4096      35154.6          1026984\n     0       720000         4096      36740.3          1023844\n     0       800000         4096      36184.6           916599\n     0       880000         4096       1282.7          1054367\n     0       960000         4096       3951.3           918773\n     0      1040000         4096      40646.2           996448\n     0      1120000         4096      43610.1           895647\n     0      1200000         4096      40333.1           921048\n\nAnd a single sync pass took:\n\n  real    0m52.407s\n  user    0m0.000s\n  sys     0m0.090s\n\nAfter the patch, there is no impact on fsmark results, and each\nindividual sync(2) operation run concurrently with the same fsmark\nworkload takes roughly 7s:\n\n  real    0m6.930s\n  user    0m0.000s\n  sys     0m0.039s\n\nIOWs, sync is 7-8x faster on a busy filesystem and does not have an\nadverse impact on ongoing async data write operations.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: I6215aecc11fb4f77c971de7b84f68649ef234360","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/0353e77a5c7057cbd6c96f527fe230c8a8274e21"},{"sha":"6b65f228c5f9e7872b4ed485addabafa8a107ab4","author":{"email":"65d484aa1efdaf0ae258f87a04ed8ec8685cba3e@samsung.com","name":"Namjae Jeon"},"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: flar2 <asegaert@gmail.com>\n\nChange-Id: I6215aecc11fb4f77c971de7b84f68649ef234361","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/6b65f228c5f9e7872b4ed485addabafa8a107ab4"},{"sha":"fbe96866808eda2131d6541f6266b30ec5b80daf","author":{"email":"adb0658383f88ec6beb1fb7689ba0dac7c1c4882@oracle.com","name":"Junxiao Bi"},"message":"writeback: fix race that cause writeback hung\n\nThere is a race between mark inode dirty and writeback thread, see the\nfollowing scenario.  In this case, writeback thread will not run though\nthere is dirty_io.\n\n__mark_inode_dirty()                                          bdi_writeback_workfn()\n\t...                                                       \t...\n\tspin_lock(&inode->i_lock);\n\t...\n\tif (bdi_cap_writeback_dirty(bdi)) {\n\t    <<< assume wb has dirty_io, so wakeup_bdi is false.\n\t    <<< the following inode_dirty also have wakeup_bdi false.\n\t    if (!wb_has_dirty_io(&bdi->wb))\n\t\t    wakeup_bdi = true;\n\t}\n\tspin_unlock(&inode->i_lock);\n\t                                                            <<< assume last dirty_io is removed here.\n\t                                                            pages_written = wb_do_writeback(wb);\n\t                                                            ...\n\t                                                            <<< work_list empty and wb has no dirty_io,\n\t                                                            <<< delayed_work will not be queued.\n\t                                                            if (!list_empty(&bdi->work_list) ||\n\t                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))\n\t                                                                queue_delayed_work(bdi_wq, &wb->dwork,\n\t                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));\n\tspin_lock(&bdi->wb.list_lock);\n\tinode->dirtied_when = jiffies;\n\t<<< new dirty_io is added.\n\tlist_move(&inode->i_wb_list, &bdi->wb.b_dirty);\n\tspin_unlock(&bdi->wb.list_lock);\n\n\t<<< though there is dirty_io, but wakeup_bdi is false,\n\t<<< so writeback thread will not be waked up and\n\t<<< the new dirty_io will not be flushed.\n\tif (wakeup_bdi)\n\t    bdi_wakeup_thread_delayed(bdi);\n\nWriteback will run until there is a new flush work queued.  This may cause\na lot of dirty pages stay in memory for a long time.\n\nSigned-off-by: Junxiao Bi <junxiao.bi@oracle.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nCc: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: Ieae0bfda9ff88fd42dbeaa275b4182517342e2f2","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/fbe96866808eda2131d6541f6266b30ec5b80daf"},{"sha":"24ec6be6d8eb13e98b2241ed3332d8d047101b94","author":{"email":"4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","name":"Davidlohr Bueso"},"message":"futexes: Increase hash table size for better performance\n\nCurrently, the futex global hash table suffers from its fixed,\nsmallish (for today's standards) size of 256 entries, as well as\nits lack of NUMA awareness. Large systems, using many futexes,\ncan be prone to high amounts of collisions; where these futexes\nhash to the same bucket and lead to extra contention on the same\nhb->lock. Furthermore, cacheline bouncing is a reality when we\nhave multiple hb->locks residing on the same cacheline and\ndifferent futexes hash to adjacent buckets.\n\nThis patch keeps the current static size of 16 entries for small\nsystems, or otherwise, 256 * ncpus (or larger as we need to\nround the number to a power of 2). Note that this number of CPUs\naccounts for all CPUs that can ever be available in the system,\ntaking into consideration things like hotpluging. While we do\nimpose extra overhead at bootup by making the hash table larger,\nthis is a one time thing, and does not shadow the benefits of\nthis patch.\n\nFurthermore, as suggested by tglx, by cache aligning the hash\nbuckets we can avoid access across cacheline boundaries and also\navoid massive cache line bouncing if multiple cpus are hammering\naway at different hash buckets which happen to reside in the\nsame cache line.\n\nAlso, similar to other core kernel components (pid, dcache,\ntcp), by using alloc_large_system_hash() we benefit from its\nNUMA awareness and thus the table is distributed among the nodes\ninstead of in a single one.\n\nFor a custom microbenchmark that pounds on the uaddr hashing --\nmaking the wait path fail at futex_wait_setup() returning\n-EWOULDBLOCK for large amounts of futexes, we can see the\nfollowing benefits on a 80-core, 8-socket 1Tb server:\n\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n | threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec) | large table+aligned (ops/sec) |\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n |     512 |              32426 | 50531  (+55.8%)        | 255274  (+687.2%)     | 292553  (+802.2%)             |\n |     256 |              65360 | 99588  (+52.3%)        | 443563  (+578.6%)     | 508088  (+677.3%)             |\n |     128 |             125635 | 200075 (+59.2%)        | 742613  (+491.1%)     | 835452  (+564.9%)             |\n |      80 |             193559 | 323425 (+67.1%)        | 1028147 (+431.1%)     | 1130304 (+483.9%)             |\n |      64 |             247667 | 443740 (+79.1%)        | 997300  (+302.6%)     | 1145494 (+362.5%)             |\n |      32 |             628412 | 721401 (+14.7%)        | 965996  (+53.7%)      | 1122115 (+78.5%)              |\n +---------+--------------------+------------------------+-----------------------+-------------------------------+\n\nReviewed-by: Darren Hart <dvhart@linux.intel.com>\nReviewed-by: Peter Zijlstra <peterz@infradead.org>\nReviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-and-tested-by: Jason Low <jason.low2@hp.com>\nReviewed-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nLink: http://lkml.kernel.org/r/1389569486-25487-3-git-send-email-davidlohr@hp.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nModified for Nexus 9\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\n\nConflicts:\n\tkernel/futex.c\n\nConflicts:\n\tkernel/futex.c\n\nConflicts:\n\tkernel/futex.c\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c6c8","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/24ec6be6d8eb13e98b2241ed3332d8d047101b94"},{"sha":"b9d8caee8063b5652ff9f247e58a388116235d8a","author":{"email":"00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","name":"Thomas Gleixner"},"message":"futex-prevent-requeue-pi-on-same-futex.patch futex: Forbid uaddr == u…\n\n…addr2 in futex_requeue(..., requeue_pi=1)\n\nIf uaddr == uaddr2, then we have broken the rule of only requeueing from\na non-pi futex to a pi futex with this call.  If we attempt this, then\ndangling pointers may be left for rt_waiter resulting in an exploitable\ncondition.\n\nThis change brings futex_requeue() in line with futex_wait_requeue_pi()\nwhich performs the same check as per commit 6f7b0a2a5c0f (\"futex: Forbid\nuaddr == uaddr2 in futex_wait_requeue_pi()\")\n\n[ tglx: Compare the resulting keys as well, as uaddrs might be\n  \tdifferent depending on the mapping ]\n\nFixes CVE-2014-3153.\n\nChange-Id: I3d40911aca262eaefc3852327fa12bec416cd27d\nReported-by: Pinkie Pie\nSigned-off-by: Will Drewry <wad@chromium.org>\nSigned-off-by: Kees Cook <keescook@chromium.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nReviewed-by: Darren Hart <dvhart@linux.intel.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/b9d8caee8063b5652ff9f247e58a388116235d8a"},{"sha":"9e0018300e46149d6a096860691e018977da90eb","author":{"email":"51b0aed1a48556115b152d4619664105ddea9243@lge.com","name":"Kyungsik Lee"},"message":"Shamu: Add LZ4 compression\n\ndecompressor: add LZ4 decompressor module\n\nAdd support for LZ4 decompression in the Linux Kernel.  LZ4 Decompression\nAPIs for kernel are based on LZ4 implementation by Yann Collet.\n\nBenchmark Results(PATCH v3)\nCompiler: Linaro ARM gcc 4.6.2\n\n1. ARMv7, 1.5GHz based board\n   Kernel: linux 3.4\n   Uncompressed Kernel Size: 14MB\n        Compressed Size  Decompression Speed\n   LZO  6.7MB            20.1MB/s, 25.2MB/s(UA)\n   LZ4  7.3MB            29.1MB/s, 45.6MB/s(UA)\n\n2. ARMv7, 1.7GHz based board\n   Kernel: linux 3.7\n   Uncompressed Kernel Size: 14MB\n        Compressed Size  Decompression Speed\n   LZO  6.0MB            34.1MB/s, 52.2MB/s(UA)\n   LZ4  6.5MB            86.7MB/s\n- UA: Unaligned memory Access support\n- Latest patch set for LZO applied\n\nThis patch set is for adding support for LZ4-compressed Kernel.  LZ4 is a\nvery fast lossless compression algorithm and it also features an extremely\nfast decoder [1].\n\nBut we have five of decompressors already and one question which does\narise, however, is that of where do we stop adding new ones?  This issue\nhad been discussed and came to the conclusion [2].\n\nRussell King said that we should have:\n\n - one decompressor which is the fastest\n - one decompressor for the highest compression ratio\n - one popular decompressor (eg conventional gzip)\n\nIf we have a replacement one for one of these, then it should do exactly\nthat: replace it.\n\nThe benchmark shows that an 8% increase in image size vs a 66% increase\nin decompression speed compared to LZO(which has been known as the\nfastest decompressor in the Kernel).  Therefore the \"fast but may not be\nsmall\" compression title has clearly been taken by LZ4 [3].\n\n[1] http://code.google.com/p/lz4/\n[2] http://thread.gmane.org/gmane.linux.kbuild.devel/9157\n[3] http://thread.gmane.org/gmane.linux.kbuild.devel/9347\n\nLZ4 homepage: http://fastcompression.blogspot.com/p/lz4.html\nLZ4 source repository: http://code.google.com/p/lz4/\n\nSigned-off-by: Kyungsik Lee <kyungsik.lee@lge.com>\nSigned-off-by: Yann Collet <yann.collet.73@gmail.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Russell King <rmk@arm.linux.org.uk>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Florian Fainelli <florian@openwrt.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nlib: add support for LZ4-compressed kernel\n\nAdd support for extracting LZ4-compressed kernel images, as well as\nLZ4-compressed ramdisk images in the kernel boot process.\n\nSigned-off-by: Kyungsik Lee <kyungsik.lee@lge.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Russell King <rmk@arm.linux.org.uk>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Florian Fainelli <florian@openwrt.org>\nCc: Yann Collet <yann.collet.73@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nlib: add lz4 compressor module\n\nThis patchset is for supporting LZ4 compression and the crypto API using\nit.\n\nAs shown below, the size of data is a little bit bigger but compressing\nspeed is faster under the enabled unaligned memory access.  We can use\nlz4 de/compression through crypto API as well.  Also, It will be useful\nfor another potential user of lz4 compression.\n\nlz4 Compression Benchmark:\nCompiler: ARM gcc 4.6.4\nARMv7, 1 GHz based board\n   Kernel: linux 3.4\n   Uncompressed data Size: 101 MB\n         Compressed Size  compression Speed\n   LZO   72.1MB\t\t  32.1MB/s, 33.0MB/s(UA)\n   LZ4   75.1MB\t\t  30.4MB/s, 35.9MB/s(UA)\n   LZ4HC 59.8MB\t\t   2.4MB/s,  2.5MB/s(UA)\n- UA: Unaligned memory Access support\n- Latest patch set for LZO applied\n\nThis patch:\n\nAdd support for LZ4 compression in the Linux Kernel.  LZ4 Compression APIs\nfor kernel are based on LZ4 implementation by Yann Collet and were changed\nfor kernel coding style.\n\nLZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html\nLZ4 source repository : http://code.google.com/p/lz4/\nsvn revision : r90\n\nTwo APIs are added:\n\nlz4_compress() support basic lz4 compression whereas lz4hc_compress()\nsupport high compression or CPU performance get lower but compression\nratio get higher.  Also, we require the pre-allocated working memory with\nthe defined size and destination buffer must be allocated with the size of\nlz4_compressbound.\n\n[akpm@linux-foundation.org: make lz4_compresshcctx() static]\nSigned-off-by: Chanho Min <chanho.min@lge.com>\nCc: \"Darrick J. Wong\" <djwong@us.ibm.com>\nCc: Bob Pearson <rpearson@systemfabricworks.com>\nCc: Richard Weinberger <richard@nod.at>\nCc: Herbert Xu <herbert@gondor.hengli.com.au>\nCc: Yann Collet <yann.collet.73@gmail.com>\nCc: Kyungsik Lee <kyungsik.lee@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c6c7\n\ncrypto: add lz4 Cryptographic API\n\nAdd support for lz4 and lz4hc compression algorithm using the lib/lz4/*\ncodebase.\n\n[akpm@linux-foundation.org: fix warnings]\nSigned-off-by: Chanho Min <chanho.min@lge.com>\nCc: \"Darrick J. Wong\" <djwong@us.ibm.com>\nCc: Bob Pearson <rpearson@systemfabricworks.com>\nCc: Richard Weinberger <richard@nod.at>\nCc: Herbert Xu <herbert@gondor.hengli.com.au>\nCc: Yann Collet <yann.collet.73@gmail.com>\nCc: Kyungsik Lee <kyungsik.lee@lge.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nlib/lz4: correct the LZ4 license\n\nThe LZ4 code is listed as using the \"BSD 2-Clause License\".\n\nSigned-off-by: Richard Laager <rlaager@wiktel.com>\nAcked-by: Kyungsik Lee <kyungsik.lee@lge.com>\nCc: Chanho Min <chanho.min@lge.com>\nCc: Richard Yao <ryao@gentoo.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\n[ The 2-clause BSD can be just converted into GPL, but that's rude and\n  pointless, so don't do it   - Linus ]\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nlz4: fix compression/decompression signedness mismatch\n\nLZ4 compression and decompression functions require different in\nsignedness input/output parameters: unsigned char for compression and\nsigned char for decompression.\n\nChange decompression API to require \"(const) unsigned char *\".\n\nSigned-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>\nCc: Kyungsik Lee <kyungsik.lee@lge.com>\nCc: Geert Uytterhoeven <geert@linux-m68k.org>\nCc: Yann Collet <yann.collet.73@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nlz4: ensure length does not wrap\n\nGiven some pathologically compressed data, lz4 could possibly decide to\nwrap a few internal variables, causing unknown things to happen.  Catch\nthis before the wrapping happens and abort the decompression.\n\nChange-Id: I055b70a212d4c0f3f2ad8e57eebec6ce8aa8b4a6\nReported-by: \"Don A. Bailey\" <donb@securitymouse.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nlz4: fix another possible overrun\n\nThere is one other possible overrun in the lz4 code as implemented by\nLinux at this point in time (which differs from the upstream lz4\ncodebase, but will get synced at in a future kernel release.)  As\npointed out by Don, we also need to check the overflow in the data\nitself.\n\nWhile we are at it, replace the odd error return value with just a\n\"simple\" -1 value as the return value is never used for anything other\nthan a basic \"did this work or not\" check.\n\nChange-Id: I839144f135e2a4eb3c1fdcf1fa418ea34d481ea3\nReported-by: \"Don A. Bailey\" <donb@securitymouse.com>\nReported-by: Willy Tarreau <w@1wt.eu>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nlz4: add overrun checks to lz4_uncompress_unknownoutputsize()\n\nJan points out that I forgot to make the needed fixes to the\nlz4_uncompress_unknownoutputsize() function to mirror the changes done\nin lz4_decompress() with regards to potential pointer overflows.\n\nThe only in-kernel user of this function is the zram code, which only\ntakes data from a valid compressed buffer that it made itself, so it's\nnot a big issue.  But due to external kernel modules using this\nfunction, it's better to be safe here.\n\nChange-Id: If7e9e5778ef7f8b6b28d34e8a1143e7f929a51e6\nReported-by: Jan Beulich <JBeulich@suse.com>\nCc: \"Don A. Bailey\" <donb@securitymouse.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\narm: add support for LZ4-compressed kernel\n\nIntegrates the LZ4 decompression code to the arm pre-boot code.\n\nSigned-off-by: Kyungsik Lee <kyungsik.lee@lge.com>\nCc: \"H. Peter Anvin\" <hpa@zytor.com>\nCc: Ingo Molnar <mingo@elte.hu>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Russell King <rmk@arm.linux.org.uk>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Florian Fainelli <florian@openwrt.org>\nCc: Yann Collet <yann.collet.73@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c6c7","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/9e0018300e46149d6a096860691e018977da90eb"},{"sha":"0f517b41628e797c4876a9e297661fb85d9eed94","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"faux123"},"message":"Optimized ARM RWSEM algorithm\n\nRWSEM implementation for ARM using atomic functions.\nHeavily based on arch/sh/include/asm/rwsem.h\n\nSigned-off-by: Ashwin Chaugule <ashwinc@codeaurora.org>\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c6c9","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/0f517b41628e797c4876a9e297661fb85d9eed94"},{"sha":"0ee58f6f9cd66d87dee9d0cbff8628458d08de32","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: crypto: add NEON accelerated XOR implementation\n\nAdd a source file xor-neon.c (which is really just the reference\nC implementation passed through the GCC vectorizer) and hook it\nup to the XOR framework.\n\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\n\nChange-Id: Iaf799f7661a3249276b7040bce1b26ebc1e99397","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/0ee58f6f9cd66d87dee9d0cbff8628458d08de32"},{"sha":"9528d5c57b628d02818588d54a1c66f85a4abec4","author":{"email":"39ea6a09710987173e32e37c86918024a0f441c1@suse.de","name":"Mel Gorman"},"message":"mm: slub: Default slub_max_order to 0\n\nTo avoid locking and per-cpu overhead, SLUB optimisically uses\nhigh-order allocations up to order-3 by default and falls back to\nlower allocations if they fail. While care is taken that the caller\nand kswapd take no unusual steps in response to this, there are\nfurther consequences like shrinkers who have to free more objects to\nrelease any memory. There is anecdotal evidence that significant time\nis being spent looping in shrinkers with insufficient progress being\nmade (https://lkml.org/lkml/2011/4/28/361) and keeping kswapd awake.\n\nSLUB is now the default allocator and some bug reports have been\npinned down to SLUB using high orders during operations like\ncopying large amounts of data. SLUBs use of high-orders benefits\napplications that are sized to memory appropriately but this does not\nnecessarily apply to large file servers or desktops.  This patch\ncauses SLUB to use order-0 pages like SLAB does by default.\nThere is further evidence that this keeps kswapd's usage lower\n(https://lkml.org/lkml/2011/5/10/383).\n\nSigned-off-by: Mel Gorman <mgorman@suse.de>\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c7c7","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/9528d5c57b628d02818588d54a1c66f85a4abec4"},{"sha":"0cc762108bbee48bdf7b325f32f161446d1ba573","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"AIO: Don't plug the I/O queue in do_io_submit()\n\nSigned-off-by: flar2 <asegaert@gmail.com>\n\nChange-Id: If6cf6e35942947e0e96d5c20acfe98c68cc7c6c1","distinct":true,"url":"https://api.github.com/repos/moepda/android_kernel_moto_shamu/commits/0cc762108bbee48bdf7b325f32f161446d1ba573"}]}