{"push_id":903487155,"size":158,"distinct_size":158,"ref":"refs/heads/cm-13.0","head":"adaf9392649b1c8d017b004b7023558842ce4aa3","before":"1f4b981e1a3089ed5459c66bc9ebebb040435b10","commits":[{"sha":"7c21a807dca5515c20bd0ac2d9d9d201bba4536a","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"mdss: use an interruptible thread on edp to reduce load_average\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/7c21a807dca5515c20bd0ac2d9d9d201bba4536a"},{"sha":"831a40fc99e98e1d67240879f8828b57f434efe2","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"msm: Use interruptible wait to not affect load average\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/831a40fc99e98e1d67240879f8828b57f434efe2"},{"sha":"62d9478e9f2add27606936c8b6a2c44718f5988d","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"msm: Use interruptible wait to not affect load average\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/62d9478e9f2add27606936c8b6a2c44718f5988d"},{"sha":"8e225a193046dd6f76a072708fc92e28ae0ad679","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"usb: ks_bridge: disable debugging\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/8e225a193046dd6f76a072708fc92e28ae0ad679"},{"sha":"cb6c5849c876077cbcee9261ef04494da403ff0c","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"msm: mpm: disable debugging\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/cb6c5849c876077cbcee9261ef04494da403ff0c"},{"sha":"12bdd860483d6ba09660a85aa079824ccbb8af1e","author":{"email":"7d26b35203412f18a7dea4f8e1db1a75b1c5b706@semaphore.gr","name":"Stratos Karafotis"},"message":"cpufreq: Break out early when frequency equals target_freq\n\nMany drivers keep frequencies in frequency table in ascending\nor descending order. When governor tries to change to policy->min\nor policy->max respectively then the cpufreq_frequency_table_target\ncould return on first iteration. This will save some iteration cycles.\n\nSo, break out early when a frequency in cpufreq_frequency_table\nequals to target one.\n\nTesting this during kernel compilation using ondemand governor\nwith a frequency table in ascending order, the\ncpufreq_frequency_table_target returned early on the first\niteration at about 30% of times called.\n\nSigned-off-by: Stratos Karafotis <stratosk@semaphore.gr>\nAcked-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/12bdd860483d6ba09660a85aa079824ccbb8af1e"},{"sha":"bd07247bbb9d0ef87f91b221cf1ac89c30f9223d","author":{"email":"10f5d60ce5fa6fe3c789dd71c5d6567abd91f3fa@google.com","name":"Tahsin Erdogan"},"message":"block: Make CFQ default to IOPS mode on SSDs\n\nCFQ idling causes reduced IOPS throughput on non-rotational disks.\nSince disk head seeking is not applicable to SSDs, it doesn't really\nhelp performance by anticipating future near-by IO requests.\n\nBy turning off idling (and switching to IOPS mode), we allow other\nprocesses to dispatch IO requests down to the driver and so increase IO\nthroughput.\n\nFollowing FIO benchmark results were taken on a cloud SSD offering with\nidling on and off:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On     7054    90.107         38.697     28217KB/s\n   Off    29255    21.836         11.730    117022KB/s\n\nfio --name=temp --size=100G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/dev/sdb --runtime=10 --iodepth=64 --numjobs=10\n\nAnd the following is from a local SSD run:\n\nIdling     iops    avg-lat(ms)    stddev            bw\n------------------------------------------------------\n    On    19320    33.043         14.068     77281KB/s\n   Off    21626    29.465         12.662     86507KB/s\n\nfio --name=temp --size=5G --time_based --ioengine=libaio \\\n    --randrepeat=0 --direct=1 --invalidate=1 --verify=0 \\\n    --verify_fatal=0 --rw=randread --blocksize=4k --group_reporting=1 \\\n    --filename=/fio_data --runtime=10 --iodepth=64 --numjobs=10\n\nChange-Id: I2311c1b349092d5d6afe5200037f6aeccf506e04\nReviewed-by: Nauman Rafique <nauman@google.com>\nSigned-off-by: Tahsin Erdogan <tahsin@google.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/bd07247bbb9d0ef87f91b221cf1ac89c30f9223d"},{"sha":"0ea6c491804a06eb70441cf1efb6e756c956a5b9","author":{"email":"cd8c6775e60d6f67a6984377324e5290df3d5358@fb.com","name":"Jens Axboe"},"message":"cfq-iosched: fix the setting of IOPS mode on SSDs\n\nA previous commit wanted to make CFQ default to IOPS mode on\nnon-rotational storage, however it did so when the queue was\ninitialized and the non-rotational flag is only set later on\nin the probe.\n\nAdd an elevator hook that gets called off the add_disk() path,\nat that point we know that feature probing has finished, and\nwe can reliably check for the various flags that drivers can\nset.\n\nChange-Id: Ieaf0beed1efc0ace7e61766e725647c6509e9852\nFixes: 41c0126b (\"block: Make CFQ default to IOPS mode on SSDs\")\nTested-by: Romain Francoise <romain@orebokech.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/0ea6c491804a06eb70441cf1efb6e756c956a5b9"},{"sha":"c9f30301b7978397bbeaf8b9f7b3f31a06d05759","author":{"email":"bece199d04f3dd7698e386ce6d24b866b933be5a@codeaurora.org","name":"Nikhilesh Reddy"},"message":"fs: Workaround the compiler's bad optimization\n\nWhen compiling the kernel with  the compiler\n\"aarch64-linux-android-gcc (GCC) 4.9.x-google 20140827 (prerelease)\"\nThe compiler seems to be optimizing a value out in the do_sync_write\nfunction and is incorrectly passing the pointer instead of the\ndereferenced value.\nForce the compiler to use the right value by passing the dereferenced\npointer instead of another variable that is assigned with the dereferenced\nvalue.\n\nChange-Id: I60505ffe39393f6323dcc7c6f912c74ea6aca6cd\nSigned-off-by: Nikhilesh Reddy <reddyn@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/c9f30301b7978397bbeaf8b9f7b3f31a06d05759"},{"sha":"4edaa5b0077b9e43e39ed0313e0454b1556bc745","author":{"email":"695912e9a92fbf1491499dabcbfa8b6645fca07f@codeaurora.org","name":"Harshdeep Dhatt"},"message":"msm: kgsl: Zero out the top 32 bits of alwayson reads\n\nThe top 32 bits of alwayson when read through CPU can\nsometimes be incorrect because of hardware race condition between\nCP and CPU. Therefore, zero out the top 32 bits before returning\nto user.\n\nConflicts:\n\n        drivers/gpu/msm/adreno_ringbuffer.c\n\nCRs-Fixed: 864922\nChange-Id: I8c0addce5627168d15ce43218cd26195a4f40c6b\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/4edaa5b0077b9e43e39ed0313e0454b1556bc745"},{"sha":"367dd8aae8cc5731a3c88250d690f9a52ab2af4c","author":{"email":"695912e9a92fbf1491499dabcbfa8b6645fca07f@codeaurora.org","name":"Harshdeep Dhatt"},"message":"msm: kgsl: Program Secure Block Configuration through CP\n\nThe TSB block registers are going to be protected by TZ. This\nmeans they can no longer be accessed through CPU, as it will cause\nXPU violation. Therefore, configure those registers through GPU\ninstead of CPU. The choice between CPU and GPU is dynamically\nimplemented in order to avoid hard dependency on TZ.\n\nCRs-Fixed: 817449\nChange-Id: Iffd443781632250afc17a795bdfaa475756bca8b\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/367dd8aae8cc5731a3c88250d690f9a52ab2af4c"},{"sha":"c70d17804eab4a67f0ecebf7044b275eb4a219f2","author":{"email":"695912e9a92fbf1491499dabcbfa8b6645fca07f@codeaurora.org","name":"Harshdeep Dhatt"},"message":"msm: kgsl: Fix race condition in snapshot sysfs read\n\nIf there are concurrent sysfs reads of snapshot binary\nthere can be a race condition where the snapshot data\nis prematurely free'd by one reader while the other reader\nis still reading it. Fix this by proper refcounting using\nan atomic.\n\nCRs-Fixed: 902816\nChange-Id: I7a156c3a22f5475df0394ae30328d0fd6140f3da\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/c70d17804eab4a67f0ecebf7044b275eb4a219f2"},{"sha":"c5b290db9ba71be3d1e5ae3a9059ef44b9c58a1a","author":{"email":"085868db2d6ba2a7f6d5f0d0ec84f03858489acc@codeaurora.org","name":"ywen"},"message":"msm: kgsl: Add return statement for non-void function\n\nIn function adreno_ringbuffer_read_pfp_ucode, the return statement\nwas missing in error path.\n\nChange-Id: I76743e776f96f11313b7c7471965d78f8fe974d1\nSigned-off-by: Yanshan Wen <ywen@codeaurora.org>\nSigned-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/c5b290db9ba71be3d1e5ae3a9059ef44b9c58a1a"},{"sha":"282a7b21843fee44408f76abfdc681a5cdbbe40c","author":{"email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","name":"Peter Zijlstra"},"message":"sched/idle: Avoid spurious wakeup IPIs\n\nBecause mwait_idle_with_hints() gets called from !idle context it must\ncall current_clr_polling(). This however means that resched_task() is\nvery likely to send an IPI even when we were polling:\n\n  CPU0\t\t\t\t\tCPU1\n\n  if (current_set_polling_and_test())\n    goto out;\n\n  __monitor(&ti->flags);\n  if (!need_resched())\n    __mwait(eax, ecx);\n\t\t\t\t\tset_tsk_need_resched(p);\n\t\t\t\t\tsmp_mb();\nout:\n  current_clr_polling();\n\t\t\t\t\tif (!tsk_is_polling(p))\n\t\t\t\t\t  smp_send_reschedule(cpu);\n\nSo while it is correct (extra IPIs aren't a problem, whereas a missed\nIPI would be) it is a performance problem (for some).\n\nAvoid this issue by using fetch_or() to atomically set NEED_RESCHED\nand test if POLLING_NRFLAG is set.\n\nSince a CPU stuck in mwait is unlikely to modify the flags word,\ncontention on the cmpxchg is unlikely and thus we should mostly\nsucceed in a single go.\n\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/n/tip-kf5suce6njh5xf5d3od13rr0@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/282a7b21843fee44408f76abfdc681a5cdbbe40c"},{"sha":"5857537a0be0eb5f0cd0937851465fa7f453e13a","author":{"email":"4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","name":"Lai Jiangshan"},"message":"kthread_work: wake up worker only when the worker is idle\n\nIf the worker is already executing a work item when another is queued,\nwe can safely skip wakeup without worrying about stalling queue thus\navoiding waking up the busy worker spuriously.  Spurious wakeups\nshould be fine but still isn't nice and avoiding it is trivial here.\n\ntj: Updated description.\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/5857537a0be0eb5f0cd0937851465fa7f453e13a"},{"sha":"2e4276e5bec939bd5466e77dfcddfb7e28ab80e7","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: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/2e4276e5bec939bd5466e77dfcddfb7e28ab80e7"},{"sha":"94451ce71a4c04b9067d4893930ab3f6d941375f","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"mm: get rid of 'vmalloc_info' from /proc/meminfo\n\nIt turns out that at least some versions of glibc end up reading\n/proc/meminfo at every single startup, because glibc wants to know the\namount of memory the machine has.  And while that's arguably insane,\nit's just how things are.\n\nAnd it turns out that it's not all that expensive most of the time, but\nthe vmalloc information statistics (amount of virtual memory used in the\nvmalloc space, and the biggest remaining chunk) can be rather expensive\nto compute.\n\nThe 'get_vmalloc_info()' function actually showed up on my profiles as\n4% of the CPU usage of \"make test\" in the git source repository, because\nthe git tests are lots of very short-lived shell-scripts etc.\n\nIt turns out that apparently this same silly vmalloc info gathering\nshows up on the facebook servers too, according to Dave Jones.  So it's\nnot just \"make test\" for git.\n\nWe had two patches to just cache the information (one by me, one by\nIngo) to mitigate this issue, but the whole vmalloc information of of\nrather dubious value to begin with, and people who *actually* want to\nknow what the situation is wrt the vmalloc area should just look at the\nmuch more complete /proc/vmallocinfo instead.\n\nIn fact, according to my testing - and perhaps more importantly,\naccording to that big search engine in the sky: Google - there is\nnothing out there that actually cares about those two expensive fields:\nVmallocUsed and VmallocChunk.\n\nSo let's try to just remove them entirely.  Actually, this just removes\nthe computation and reports the numbers as zero for now, just to try to\nbe minimally intrusive.\n\nIf this breaks anything, we'll obviously have to re-introduce the code\nto compute this all and add the caching patches on top.  But if given\nthe option, I'd really prefer to just remove this bad idea entirely\nrather than add even more code to work around our historical mistake\nthat likely nobody really cares about.\n\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\n\tfs/proc/meminfo.c\n\tinclude/linux/vmalloc.h\n\tmm/vmalloc.c\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/94451ce71a4c04b9067d4893930ab3f6d941375f"},{"sha":"c150058e34ea95a578a0b2eeda202ed9d038998a","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"vfs: Fix pathological performance case for __alloc_fd()\n\nAl Viro points out that:\n> >     * [Linux-specific aside] our __alloc_fd() can degrade quite badly\n> > with some use patterns.  The cacheline pingpong in the bitmap is probably\n> > inevitable, unless we accept considerably heavier memory footprint,\n> > but we also have a case when alloc_fd() takes O(n) and it's _not_ hard\n> > to trigger - close(3);open(...); will have the next open() after that\n> > scanning the entire in-use bitmap.\n\nAnd Eric Dumazet has a somewhat realistic multithreaded microbenchmark\nthat opens and closes a lot of sockets with minimal work per socket.\n\nThis patch largely fixes it.  We keep a 2nd-level bitmap of the open\nfile bitmaps, showing which words are already full.  So then we can\ntraverse that second-level bitmap to efficiently skip already allocated\nfile descriptors.\n\nOn his benchmark, this improves performance by up to an order of\nmagnitude, by avoiding the excessive open file bitmap scanning.\n\nTested-and-acked-by: Eric Dumazet <edumazet@google.com>\nCc: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/c150058e34ea95a578a0b2eeda202ed9d038998a"},{"sha":"77291bfb2a90c69a86911f807d1918f10dd0e8c9","author":{"email":"69652caca27c8b940640ad396ab71f93cacec34f@linux-foundation.org","name":"Linus Torvalds"},"message":"vfs: conditionally clear close-on-exec flag\n\nWe clear the close-on-exec flag when opening and closing files, and the\nbit was almost always already clear before.  Avoid dirtying the\ncacheline if the clearning isn't necessary.  That avoids unnecessary\ncacheline dirtying and bouncing in multi-socket environments.\n\nEric Dumazet has a file descriptor benchmark that goes 4% faster from\nthis on his two-socket machine.  It's probably partly superlinear\nimprovement due to getting slightly less spinlock contention on the\nfile_lock spinlock due to less work in the critical section.\n\nTested-by: Eric Dumazet <eric.dumazet@gmail.com>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/77291bfb2a90c69a86911f807d1918f10dd0e8c9"},{"sha":"cee325cce055b8ead8e6d0aa5d8d9e59580a4e78","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"Remove '+' symbol from kernel version string\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/zyonee/android_kernel_huawei_angler/commits/cee325cce055b8ead8e6d0aa5d8d9e59580a4e78"}]}