{"push_id":2068373092,"size":12,"distinct_size":12,"ref":"refs/heads/cm-13.0","head":"969720e990ae891a8fc6d454fe17078968f168f7","before":"2210f616c7a2bba41b3ccf3b55c9976dcce9b9cf","commits":[{"sha":"07d2457a55926d45239bbaacca29ebc2ef843139","author":{"name":"EfranDev","email":"df3f35c518ca304e55cf1be91a98bd04b8f15ef1@hotmail.com"},"message":"defconfig: enable WQ_POWER_EFFICIENT","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/07d2457a55926d45239bbaacca29ebc2ef843139"},{"sha":"6395ce9c10a7fd42266e20aa5f1546dd5808efb0","author":{"name":"EfranDev","email":"df3f35c518ca304e55cf1be91a98bd04b8f15ef1@hotmail.com"},"message":"defconfig: update: enable all available features","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/6395ce9c10a7fd42266e20aa5f1546dd5808efb0"},{"sha":"b57e3eced636cc852951e7a188a63d70d361c11f","author":{"name":"EfranDev","email":"df3f35c518ca304e55cf1be91a98bd04b8f15ef1@hotmail.com"},"message":"defconfig: enable advanced TCP congestions","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/b57e3eced636cc852951e7a188a63d70d361c11f"},{"sha":"fdffca9f44327a0a76867624a390c28d36a1fd40","author":{"name":"EfranDev","email":"df3f35c518ca304e55cf1be91a98bd04b8f15ef1@hotmail.com"},"message":"defconfig: Enable pstore\nNew location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops.\nOn Android, diagnosing kernel crashes often requires a developer to read the /proc/last_kmsg file, which stores previous kernel logs after a reboot. Unfortunately it went missing in Android 6.0.\nIt turns out that it was moved to /sys/fs/pstore/console-ramoops . It still works the same way as before (cat /sys/fs/pstore/console-ramoops will display the previous kernel log).\n\nSource: https://sites.google.com/site/zhuoweisite/blog/newlocationoflastkmsgonandroid60andabovesysfspstoreconsole-ramoops","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/fdffca9f44327a0a76867624a390c28d36a1fd40"},{"sha":"55a6c3f9a39816acb4a5181b346e763b528afc52","author":{"name":"Steve Kondik","email":"5eb4f8ae09d1b5661f1add989b1c3fabe443bd83@cyngn.com"},"message":"qpnp-haptic: Dejank the haptics\n\n* Remove OEM patch which actually makes the jank worse\n * Add mutexes and call hap_set without the workqueue for direct mode\n\nChange-Id: I98f5b8ddea572def2706ad2cfa18f9dd460757ed","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/55a6c3f9a39816acb4a5181b346e763b528afc52"},{"sha":"7457598ebdc9311a10c4dff410084c8502ccb264","author":{"name":"Neal Cardwell","email":"6eb0de8c52d8a3fcaae13b97cd10ce8592d0bd4f@google.com"},"message":"tcp: fix timing issue in CUBIC slope calculation\n\nThis patch fixes a bug in CUBIC that causes cwnd to increase slightly\ntoo slowly when multiple ACKs arrive in the same jiffy.\n\nIf cwnd is supposed to increase at a rate of more than once per jiffy,\nthen CUBIC was sometimes too slow. Because the bic_target is\ncalculated for a future point in time, calculated with time in\njiffies, the cwnd can increase over the course of the jiffy while the\nbic_target calculated as the proper CUBIC cwnd at time\nt=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only\nincreases on jiffy tick boundaries.\n\nSo since the cnt is set to:\n\tca->cnt = cwnd / (bic_target - cwnd);\nas cwnd increases but bic_target does not increase due to jiffy\ngranularity, the cnt becomes too large, causing cwnd to increase\ntoo slowly.\n\nFor example:\n- suppose at the beginning of a jiffy, cwnd=40, bic_target=44\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10\n- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()\n   increases cwnd to 41\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13\n\nSo now CUBIC will wait for 13 packets to be ACKed before increasing\ncwnd to 42, insted of 10 as it should.\n\nThe fix is to avoid adjusting the slope (determined by ca->cnt)\nmultiple times within a jiffy, and instead skip to compute the Reno\ncwnd, the \"TCP friendliness\" code path.\n\nReported-by: Eyal Perry <eyalpe@mellanox.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/7457598ebdc9311a10c4dff410084c8502ccb264"},{"sha":"8a190ac36d0e63dbec0919bee6302daed70e7db9","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: better follow cubic curve after idle period\n\nJana Iyengar found an interesting issue on CUBIC :\n\nThe epoch is only updated/reset initially and when experiencing losses.\nThe delta \"t\" of now - epoch_start can be arbitrary large after app idle\nas well as the bic_target. Consequentially the slope (inverse of\nca->cnt) would be really large, and eventually ca->cnt would be\nlower-bounded in the end to 2 to have delayed-ACK slow-start behavior.\n\nThis particularly shows up when slow_start_after_idle is disabled\nas a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle\ntime.\n\nJana initial fix was to reset epoch_start if app limited,\nbut Neal pointed out it would ask the CUBIC algorithm to recalculate the\ncurve so that we again start growing steeply upward from where cwnd is\nnow (as CUBIC does just after a loss). Ideally we'd want the cwnd growth\ncurve to be the same shape, just shifted later in time by the amount of\nthe idle period.\n\nChange-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b\nReported-by: Jana Iyengar <jri@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Sangtae Ha <sangtae.ha@gmail.com>\nCc: Lawrence Brakmo <lawrence@brakmo.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/8a190ac36d0e63dbec0919bee6302daed70e7db9"},{"sha":"fe32dbba943a8afcd6555be40200560232cb74fe","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: do not set epoch_start in the future\n\nTracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start\nis normally set at ACK processing time, not at send time.\n\nDoing a proper fix would need to add an additional state variable,\nand does not seem worth the trouble, given CUBIC bug has been there\nforever before Jana noticed it.\n\nLet's simply not set epoch_start in the future, otherwise\nbictcp_update() could overflow and CUBIC would again\ngrow cwnd too fast.\n\nThis was detected thanks to a packetdrill test Neal wrote that was flaky\nbefore applying this fix.\n\nChange-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3\nFixes: 30927520dbae (\"tcp_cubic: better follow cubic curve after idle period\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nCc: Jana Iyengar <jri@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/fe32dbba943a8afcd6555be40200560232cb74fe"},{"sha":"103da998da2152859b2cdca5756617dff04611e3","author":{"name":"Namjae Jeon","email":"cee0fb13a02a9f6df517d42af792ebb078f2bc1f@samsung.com"},"message":"writeback: fix writeback cache thrashing\n\nConsider Process A: huge I/O on sda\n        doing heavy write operation - dirty memory becomes more\n        than dirty_background_ratio\n        on HDD - flusher thread flush-8:0\n\nConsider Process B: small I/O on sdb\n        doing while [1]; read 1024K + rewrite 1024K + sleep 2sec\n        on Flash device - flusher thread flush-8:16\n\nAs Process A is a heavy dirtier, dirty memory becomes more\nthan dirty_background_thresh. Due to this, below check becomes\ntrue(checking global_page_state in over_bground_thresh)\nfor all bdi devices(even for very small dirtied bdi - sdb):\n\nIn this case, even small cached data on 'sdb' is forced to flush\nand writeback cache thrashing happens.\n\nWhen we added debug prints inside above 'if' condition and ran\nabove Process A(heavy dirtier on bdi with flush-8:0) and\nProcess B(1024K frequent read/rewrite on bdi with flush-8:16)\nwe got below prints:\n\n[Test setup: ARM dual core CPU, 512 MB RAM]\n\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84720 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 94720 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   384 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   960 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92160 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   768 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   256 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   320 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92032 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 91968 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =  1024 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =    64 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   576 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 84352 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   192 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =   512 KB\n[over_bground_thresh]: wakeup flush-8:16 : BDI_RECLAIMABLE =     0 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92608 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE = 92544 KB\n\nAs mentioned in above log, when global dirty memory > global background_thresh\nsmall cached data is also forced to flush by flush-8:16.\nIf removing global background_thresh checking code, we can reduce cache\nthrashing of frequently used small data.\nAnd It will be great if we can reserve a portion of writeback cache using\nmin_ratio.\n\nAfter applying patch:\n$ echo 5 > /sys/block/sdb/bdi/min_ratio\n$ cat /sys/block/sdb/bdi/min_ratio\n5\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56064 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  56704 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  84160 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  96960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  94080 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93120 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  91520 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  89600 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  93696 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  72960 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90624 KB\n[over_bground_thresh]: wakeup flush-8:0 : BDI_RECLAIMABLE =  90688 KB\n\nAs mentioned in the above logs, once cache is reserved for Process B,\nand patch is applied there is less writeback cache thrashing on sdb\nby frequent forced writeback by flush-8:16 in over_bground_thresh.\n\nAfter all, small cached data will be flushed by periodic writeback\nonce every dirty_writeback_interval.\n\nSuggested-by: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nSigned-off-by: Namjae Jeon <namjae.jeon@samsung.com>\nSigned-off-by: Vivek Trivedi <t.vivek@samsung.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/103da998da2152859b2cdca5756617dff04611e3"},{"sha":"43c385b6bdfa61cce21bf4b6936f79638ef8e69c","author":{"name":"Tim Murray","email":"1236fbd8e0651a86c12ed0f0b75aaeb5e5852ea8@google.com"},"message":"cpuidle: don't disable cpuidle when entering suspend\n\ncpuidle was disabled while entering suspend as part of commit\n8651f97bd951d0bb1c10fa24e3fa3455193f3548 in order to work around some\nACPI bugs. However, there's no reason to do this on modern\nplatforms. Leaving cpuidle enabled can result in improved power\nconsumption if dpm_resume_noirq runs for a significant time.\n\nChange-Id: Ie182785b176f448698c0264eba554d1e315e8a06","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/43c385b6bdfa61cce21bf4b6936f79638ef8e69c"},{"sha":"e571f8c4afd366561240e33629216c82df98220d","author":{"name":"Manikanta Sivapala","email":"428a3f87334f288c251029b816bd508b18e63130@codeaurora.org"},"message":"msm: vidc: disable CPU L2 cache PC during video sessions\n\nCPU L2 cache is being power collapsed and resumed during\nvideo sessions which is consuming more power unnecessarily.\nSo disable CPU L2 cache power collapse during video sessions\nusing qos requests to save power.\n\nChange-Id: Iaf47231bed1304510ea221b9d50866d3b4adfed0\nSigned-off-by: Maheshwar Ajja <majja@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/e571f8c4afd366561240e33629216c82df98220d"},{"sha":"969720e990ae891a8fc6d454fe17078968f168f7","author":{"name":"Jens Axboe","email":"f8b120bbe297304053fa957b507156696820d130@fb.com"},"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>","distinct":true,"url":"https://api.github.com/repos/Huawei-msm8937/android_kernel_huawei_msm8937/commits/969720e990ae891a8fc6d454fe17078968f168f7"}]}
{"actor":{"display_login":"EfranDev"}}