{"push_id":630446974,"size":31,"distinct_size":31,"ref":"refs/heads/gamermod","head":"733ba8813502b06a4680ab14fffafb92b453c06b","before":"a7020213bd6b352c175795117571eff84f32d64f","commits":[{"sha":"f884c45b74b81877452f887ad02fc17b94854640","author":{"email":"829500b200af6c2a0eca4dfd5c388e6b8fbe8dc6@suse.cz","name":"Michal Hocko"},"message":"memcg: prevent OOM with too many dirty pages\n\nThe current implementation of dirty pages throttling is not memcg aware\nwhich makes it easy to have memcg LRUs full of dirty pages.  Without\nthrottling, these LRUs can be scanned faster than the rate of writeback,\nleading to memcg OOM conditions when the hard limit is small.\n\nThis patch fixes the problem by throttling the allocating process\n(possibly a writer) during the hard limit reclaim by waiting on\nPageReclaim pages.  We are waiting only for PageReclaim pages because\nthose are the pages that made one full round over LRU and that means that\nthe writeback is much slower than scanning.\n\nThe solution is far from being ideal - long term solution is memcg aware\ndirty throttling - but it is meant to be a band aid until we have a real\nfix.  We are seeing this happening during nightly backups which are placed\ninto containers to prevent from eviction of the real working set.\n\nThe change affects only memcg reclaim and only when we encounter\nPageReclaim pages which is a signal that the reclaim doesn't catch up on\nwith the writers so somebody should be throttled.  This could be\npotentially unfair because it could be somebody else from the group who\ngets throttled on behalf of the writer but as writers need to allocate as\nwell and they allocate in higher rate the probability that only innocent\nprocesses would be penalized is not that high.\n\nI have tested this change by a simple dd copying /dev/zero to tmpfs or\next3 running under small memcg (1G copy under 5M, 60M, 300M and 2G\ncontainers) and dd got killed by OOM killer every time.  With the patch I\ncould run the dd with the same size under 5M controller without any OOM.\nThe issue is more visible with slower devices for output.\n\n* With the patch\n================\n* tmpfs size=2G\n---------------\n$ vim cgroup_cache_oom_test.sh\n$ ./cgroup_cache_oom_test.sh 5M\nusing Limit 5M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 30.4049 s, 34.5 MB/s\n$ ./cgroup_cache_oom_test.sh 60M\nusing Limit 60M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 31.4561 s, 33.3 MB/s\n$ ./cgroup_cache_oom_test.sh 300M\nusing Limit 300M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 20.4618 s, 51.2 MB/s\n$ ./cgroup_cache_oom_test.sh 2G\nusing Limit 2G for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 1.42172 s, 738 MB/s\n\n* ext3\n------\n$ ./cgroup_cache_oom_test.sh 5M\nusing Limit 5M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 27.9547 s, 37.5 MB/s\n$ ./cgroup_cache_oom_test.sh 60M\nusing Limit 60M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 30.3221 s, 34.6 MB/s\n$ ./cgroup_cache_oom_test.sh 300M\nusing Limit 300M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 24.5764 s, 42.7 MB/s\n$ ./cgroup_cache_oom_test.sh 2G\nusing Limit 2G for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 3.35828 s, 312 MB/s\n\n* Without the patch\n===================\n* tmpfs size=2G\n---------------\n$ ./cgroup_cache_oom_test.sh 5M\nusing Limit 5M for group\n./cgroup_cache_oom_test.sh: line 46:  4668 Killed                  dd if=/dev/zero of=$OUT/zero bs=1M count=$count\n$ ./cgroup_cache_oom_test.sh 60M\nusing Limit 60M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 25.4989 s, 41.1 MB/s\n$ ./cgroup_cache_oom_test.sh 300M\nusing Limit 300M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 24.3928 s, 43.0 MB/s\n$ ./cgroup_cache_oom_test.sh 2G\nusing Limit 2G for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 1.49797 s, 700 MB/s\n\n* ext3\n------\n$ ./cgroup_cache_oom_test.sh 5M\nusing Limit 5M for group\n./cgroup_cache_oom_test.sh: line 46:  4689 Killed                  dd if=/dev/zero of=$OUT/zero bs=1M count=$count\n$ ./cgroup_cache_oom_test.sh 60M\nusing Limit 60M for group\n./cgroup_cache_oom_test.sh: line 46:  4692 Killed                  dd if=/dev/zero of=$OUT/zero bs=1M count=$count\n$ ./cgroup_cache_oom_test.sh 300M\nusing Limit 300M for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 20.248 s, 51.8 MB/s\n$ ./cgroup_cache_oom_test.sh 2G\nusing Limit 2G for group\n1000+0 records in\n1000+0 records out\n1048576000 bytes (1.0 GB) copied, 2.85201 s, 368 MB/s\n\n[akpm@linux-foundation.org: tweak changelog, reordered the test to optimize for CONFIG_CGROUP_MEM_RES_CTLR=n]\n[hughd@google.com: fix deadlock with loop driver]\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Rik van Riel <riel@redhat.com>\nCc: Ying Han <yinghan@google.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Hugh Dickins <hughd@google.com>\nReviewed-by: Mel Gorman <mgorman@suse.de>\nAcked-by: Johannes Weiner <hannes@cmpxchg.org>\nReviewed-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: Michal Hocko <mhocko@suse.cz>\nCc: <stable@vger.kernel.org>\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>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/f884c45b74b81877452f887ad02fc17b94854640"},{"sha":"40a5439e66a03165cabcd09f7c82c0076f9743b1","author":{"email":"d3abdf3e2800e6cb849f11b81e6eb50b34d96431@google.com","name":"Hugh Dickins"},"message":"memcg: further prevent OOM with too many dirty pages\n\nThe may_enter_fs test turns out to be too restrictive: though I saw no\nproblem with it when testing on 3.5-rc6, it very soon OOMed when I tested\non 3.5-rc6-mm1.  I don't know what the difference there is, perhaps I just\nslightly changed the way I started off the testing: dd if=/dev/zero\nof=/mnt/temp bs=1M count=1024; rm -f /mnt/temp; sync repeatedly, in 20M\nmemory.limit_in_bytes cgroup to ext4 on USB stick.\n\next4 (and gfs2 and xfs) turn out to allocate new pages for writing with\nAOP_FLAG_NOFS: that seems a little worrying, and it's unclear to me why\nthe transaction needs to be started even before allocating pagecache\nmemory.  But it may not be worth worrying about these days: if direct\nreclaim avoids FS writeback, does __GFP_FS now mean anything?\n\nAnyway, we insisted on the may_enter_fs test to avoid hangs with the loop\ndevice; but since that also masks off __GFP_IO, we can test for __GFP_IO\ndirectly, ignoring may_enter_fs and __GFP_FS.\n\nBut even so, the test still OOMs sometimes: when originally testing on\n3.5-rc6, it OOMed about one time in five or ten; when testing just now on\n3.5-rc6-mm1, it OOMed on the first iteration.\n\nThis residual problem comes from an accumulation of pages under ordinary\nwriteback, not marked PageReclaim, so rightly not causing the memcg check\nto wait on their writeback: these too can prevent shrink_page_list() from\nfreeing any pages, so many times that memcg reclaim fails and OOMs.\n\nDeal with these in the same way as direct reclaim now deals with dirty FS\npages: mark them PageReclaim.  It is appropriate to rotate these to tail\nof list when writepage completes, but more importantly, the PageReclaim\nflag makes memcg reclaim wait on them if encountered again.  Increment\nNR_VMSCAN_IMMEDIATE?  That's arguable: I chose not.\n\nSetting PageReclaim here may occasionally race with end_page_writeback()\nclearing it: lru_deactivate_fn() already faced the same race, and\ncorrectly concluded that the window is small and the issue non-critical.\n\nWith these changes, the test runs indefinitely without OOMing on ext4,\next3 and ext2: I'll move on to test with other filesystems later.\n\nTrivia: invert conditions for a clearer block without an else, and goto\nkeep_locked to do the unlock_page.\n\nSigned-off-by: Hugh Dickins <hughd@google.com>\nCc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujtisu.com>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Rik van Riel <riel@redhat.com>\nCc: Ying Han <yinghan@google.com>\nCc: Greg Thelen <gthelen@google.com>\nCc: Hugh Dickins <hughd@google.com>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Johannes Weiner <hannes@cmpxchg.org>\nCc: Fengguang Wu <fengguang.wu@intel.com>\nAcked-by: Michal Hocko <mhocko@suse.cz>\nCc: Dave Chinner <david@fromorbit.com>\nCc: Theodore Ts'o <tytso@mit.edu>\nCc: <stable@vger.kernel.org>\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>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/40a5439e66a03165cabcd09f7c82c0076f9743b1"},{"sha":"ccb2a23d9de3d78230f3d70a307c2bcd093649f3","author":{"email":"59c7438a9275f5dd0b96a91958b493a9d005ad46@cn.fujitsu.com","name":"Wen Congyang"},"message":"memory hotplug: reset pgdat->kswapd to NULL if creating kernel thread fails\n\nIf kthread_run() fails, pgdat->kswapd contains errno.  When we stop this\nthread, we only check whether pgdat->kswapd is NULL and access it.  If\nit contains errno, it will cause page fault.  Reset pgdat->kswapd to\nNULL when creating kernel thread fails can avoid this problem.\n\nSigned-off-by: Wen Congyang <wency@cn.fujitsu.com>\nReviewed-by: Minchan Kim <minchan@kernel.org>\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>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/ccb2a23d9de3d78230f3d70a307c2bcd093649f3"},{"sha":"d8c7f8bdfb6d646d13eb4d20c695d74dc2b71b69","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"ARM: pull in <asm/simd.h> from asm-generic\n\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/d8c7f8bdfb6d646d13eb4d20c695d74dc2b71b69"},{"sha":"91b9a880dc581c64407f447945b99745dfe6e74c","author":{"email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org","name":"Srivatsa Vaddagiri"},"message":"sched: Fix reference to stale task_struct in try_to_wake_up()\n\ntry_to_wake_up() currently drops p->pi_lock and later checks for need\nto notify cpufreq governor on task migrations or wakeups. However the\nwoken task could exit between the time p->pi_lock is released and the\ntime the test for notification is run. As a result, the test for\nnotification could refer to an exited task. task_notify_on_migrate(p)\ncould thus lead to invalid memory reference.\n\nFix this by running the test for notification with task's pi_lock\nheld.\n\nChange-Id: I1c7a337473d2d8e79342a015a179174ce00702e1\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/91b9a880dc581c64407f447945b99745dfe6e74c"},{"sha":"c22f957d9d075cb799420680addaad5123ac73d2","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: conservative: add micro idle accounting and touch boost support\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/c22f957d9d075cb799420680addaad5123ac73d2"},{"sha":"cd8e974df63c9056aa3904aa5fbc8deee197a336","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: conservative: notify the policy of the current load\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/cd8e974df63c9056aa3904aa5fbc8deee197a336"},{"sha":"bd78e040b5ed99a768035254cdf8ed72a8f58c6c","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"EXPERIMENTAL: mako_hotplug: make cpu2 and cpu3 less nervous\n\nUsing conservative governor with 10ms sample time changed the whole cpu\nmanagement panorama. With this fine-tuning those cores won't be online\nas often as then've been since conservative was deployed (I'm getting\nthe cpu load from the governor itself). It's marked as experimental\nbecause this needs some real world testing (e.g users).\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/bd78e040b5ed99a768035254cdf8ed72a8f58c6c"},{"sha":"3bb2064ff3b1483da329f0c94cb9a97733541cd7","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: conservative: add sane input_boost and duration values\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/3bb2064ff3b1483da329f0c94cb9a97733541cd7"},{"sha":"48a8cc7f3b71c3b9a71962c71be3bc647d25999d","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":".gitignore: update\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/48a8cc7f3b71c3b9a71962c71be3bc647d25999d"},{"sha":"7118a5d5de79adac2740d3b980d81e9d08c9159c","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: conservative: how did this end up here?\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/7118a5d5de79adac2740d3b980d81e9d08c9159c"},{"sha":"6af9c5bc56d3dbb423454969ab67c92680c8f1ca","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: conservative: add input_boost_freq and input_boost_duration to sysfs\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/6af9c5bc56d3dbb423454969ab67c92680c8f1ca"},{"sha":"0396a55379ab1ad6e994735b832f410b315f2c3f","author":{"email":"d77b46f71ad07d1c66a004715c9110750816d270@motorola.com","name":"Jason Hrycay"},"message":"msm: memutils: memcpy, memmove, copy_page optimization\n\nPreload farther to take advantage of the memory bus, and assume\n64-byte cache lines.  Unroll some pairs of ldm/stm as well, for\nunexplainable reasons.\n\nFuture enhancements should include,\n\n- #define for how far to preload, possibly defined separately for\n  memcpy, copy_*_user\n- Tuning for misaligned buffers\n- Tuning for memmove\n- Tuning for small buffers\n- Understanding mechanism behind ldm/stm unroll causing some gains\n  in copy_to_user\n\nBASELINE (msm8960pro):\n======================================================================\nmemcpy 1000MB at 5MB       : took 808850 usec, bandwidth 1236.236 MB/s\ncopy_to_user 1000MB at 5MB : took 810071 usec, bandwidth 1234.234 MB/s\ncopy_from_user 1000MB at 5M: took 942926 usec, bandwidth 1060.060 MB/s\nmemmove 1000GB at 5MB      : took 848588 usec, bandwidth 1178.178 MB/s\ncopy_to_user 1000GB at 4kB : took 847916 usec, bandwidth 1179.179 MB/s\ncopy_from_user 1000GB at 4k: took 935113 usec, bandwidth 1069.069 MB/s\ncopy_page 1000GB at 4kB    : took 779459 usec, bandwidth 1282.282 MB/s\n\nTHIS PATCH:\n======================================================================\nmemcpy 1000MB at 5MB       : took 346223 usec, bandwidth 2888.888 MB/s\ncopy_to_user 1000MB at 5MB : took 348084 usec, bandwidth 2872.872 MB/s\ncopy_from_user 1000MB at 5M: took 348176 usec, bandwidth 2872.872 MB/s\nmemmove 1000GB at 5MB      : took 348267 usec, bandwidth 2871.871 MB/s\ncopy_to_user 1000GB at 4kB : took 377018 usec, bandwidth 2652.652 MB/s\ncopy_from_user 1000GB at 4k: took 371829 usec, bandwidth 2689.689 MB/s\ncopy_page 1000GB at 4kB    : took 383763 usec, bandwidth 2605.605 MB/s\n\nSigned-off-by: Chris Fries <C.Fries@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\n\nConflicts:\n\n\tarch/arm/mach-msm/Kconfig\n\tarch/arm/mach-msm/Makefile\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/0396a55379ab1ad6e994735b832f410b315f2c3f"},{"sha":"e781811d5f768ee1f65175a1b1e2163ffe4d1495","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"arm: lib: Fix makefile bug\n\nWhen HAS_MACH_MEMUTILS is defined, two version of memcpy.S would\nbe built at the same time, fix the issue here.\n\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-by: Yi-Wei Zhao <gbjc64@motorola.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/e781811d5f768ee1f65175a1b1e2163ffe4d1495"},{"sha":"75729f175e73aacaf28e824b5ae3c7c26ca00e01","author":{"email":"4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","name":"Lai Jiangshan"},"message":"smpboot: Add missing get_online_cpus() in smpboot_register_percpu_thread()\n\nThe following race exists in the smpboot percpu threads management:\n\nCPU0\t      \t   \t     CPU1\ncpu_up(2)\n  get_online_cpus();\n  smpboot_create_threads(2);\n\t\t\t     smpboot_register_percpu_thread();\n\t\t\t     for_each_online_cpu();\n\t\t\t       __smpboot_create_thread();\n  __cpu_up(2);\n\nThis results in a missing per cpu thread for the newly onlined cpu2 and\nin a NULL pointer dereference on a consecutive offline of that cpu.\n\nProctect smpboot_register_percpu_thread() with get_online_cpus() to\nprevent that.\n\n[ tglx: Massaged changelog and removed the change in\n        smpboot_unregister_percpu_thread() because that's an\n        optimization and therefor not stable material. ]\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Rusty Russell <rusty@rustcorp.com.au>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nCc: David Rientjes <rientjes@google.com>\nCc: stable@vger.kernel.org\nLink: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.com\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/75729f175e73aacaf28e824b5ae3c7c26ca00e01"},{"sha":"aaec22076e830172ca3427b4828716c533565baa","author":{"email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","name":"Peter Zijlstra"},"message":"sched, smp: Correctly deal with nested sleeps\n\nsmp_hotplug_thread::{setup,unpark} functions can sleep too, so be\nconsistent and do the same for all callbacks.\n\n __might_sleep+0x74/0x80\n kmem_cache_alloc_trace+0x4e/0x1c0\n perf_event_alloc+0x55/0x450\n perf_event_create_kernel_counter+0x2f/0x100\n watchdog_nmi_enable+0x8d/0x160\n watchdog_enable+0x45/0x90\n smpboot_thread_fn+0xec/0x2b0\n kthread+0xe4/0x100\n ret_from_fork+0x7c/0xb0\n\nSigned-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>\nCc: tglx@linutronix.de\nCc: ilya.dryomov@inktank.com\nCc: umgwanakikbuti@gmail.com\nCc: oleg@redhat.com\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/r/20140924082242.392279328@infradead.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/BlissRom/kernel_lge_hammerhead/commits/aaec22076e830172ca3427b4828716c533565baa"},{"sha":"adb1c72cbaa04a37166e7a8a03fdee1697f9184a","author":{"email":"27ffc44a8ec6a212fba98cfc3246c6ce8ab131e0@intel.com","name":"Rafael J. Wysocki"},"message":"Revert \"epoll: use freezable blocking call\"\n\nThis reverts commit 1c441e921201 (epoll: use freezable blocking call)\nwhich is reported to cause user space memory corruption to happen\nafter suspend to RAM.\n\nSince it appears to be extremely difficult to root cause this\nproblem, it is best to revert the offending commit and try to address\nthe original issue in a better way later.\n\nChange-Id: Ib57a2bda6c190454ae3bd3ae7eeb1456ea2156a6\nReferences: https://bugzilla.kernel.org/show_bug.cgi?id=61781\nReported-by: Natrio <natrio@list.ru>\nReported-by: Jeff Pohlmeyer <yetanothergeek@gmail.com>\nBisected-by: Leo Wolf <jclw@ymail.com>\nFixes: 1c441e921201 (epoll: use freezable blocking call)\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nCc: 3.11+ <stable@vger.kernel.org> # 3.11+\nGit-commit: c511851de162e8ec03d62e7d7feecbdf590d881d\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-stable.git\nSigned-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/adb1c72cbaa04a37166e7a8a03fdee1697f9184a"},{"sha":"8e47a67f5f88f2223f6cf97669eccecc73ee7032","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"input: touchboost: conservative samples every 10ms, no point in limiting input_time to update its value in 50ms intervals\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/8e47a67f5f88f2223f6cf97669eccecc73ee7032"},{"sha":"95e23e6ec6a02d79b7ee67586122c226aebe0b61","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"mako_hotplug: remove screen off frequency cap and other optimizations\n\nThere have been reports of some sound glitches during screen off\nwhich may indicate that the device might need more frequency to operate\n(specially if there are mobile radio variations, the glitches are\nmore regular). So for that reason let's leave it unlocked.\n\nAlso optimize some code for clarity.\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/BlissRom/kernel_lge_hammerhead/commits/95e23e6ec6a02d79b7ee67586122c226aebe0b61"},{"sha":"3a4ba17139d7a5b952eaa5adccad7985114a1546","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/BlissRom/kernel_lge_hammerhead/commits/3a4ba17139d7a5b952eaa5adccad7985114a1546"}]}