{"push_id":955196245,"size":67,"distinct_size":67,"ref":"refs/heads/mm6.0","head":"ebde5c5a22c4514093e90d343d070f3550996cd5","before":"ef8e14d58375188822ee9848c52f78a782358856","commits":[{"sha":"487d08fc774349900c3ca39296e4d4f27dceea8d","author":{"email":"34a322c05ccf7a69003b3e288dfc60055c6d0c33@codeaurora.org","name":"Liam Mark"},"message":"mm: vmscan: support complete shrinker reclaim\n\nEnsure that shrinkers are given the option to completely drop\ntheir caches even when their caches are smaller than the batch size.\n\nThis change helps improve memory headroom by ensuring that under\nsignificant memory pressure shrinkers can drop all of their caches.\n\nThis change only attempts to more aggressively call the shrinkers\nduring background memory reclaim inorder to avoid hurting the\nperforamnce of direct memory reclaim.\n\nChange-Id: I8dbc29c054add639e4810e36fd2c8a063e5c52f3\nSigned-off-by: Liam Mark <lmark@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/487d08fc774349900c3ca39296e4d4f27dceea8d"},{"sha":"f23ef67cca9ab5d42ffffc4da1a26694f20fbdd1","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\nChange-Id: Icbb2571c1b99f1429ece06f3ac27e25f93c95f9d\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>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/f23ef67cca9ab5d42ffffc4da1a26694f20fbdd1"},{"sha":"3133ab16329b802906f70083f4e33d19f95a69a3","author":{"email":"69d4c67d027719823df1f8f9226c47bc05dc8998@codeaurora.org","name":"Srivatsa Vaddagiri"},"message":"sched: Set MC (multi-core) sched domain's busy_factor attribute to 1\n\nbusy_factor attribute of a scheduler domain causes busy CPUs (CPUs\nthat are not idle) to load balance less frequently in that domain,\nwhich could impact performance by increasing scheduling latency for\ntasks.\n\nAs an example, consider MC scheduler domain's attribute values of\nmax_interval = 4ms and busy_factor = 64. Further consider\nmax_load_balance_interval = 100 (HZ/10). In this case, a non-idle CPU\ncould put off load balance check in MC domain by 100ms. This\neffectively means that a CPU running a single task in its queue could\nfail to notice increased load on another CPU (that is in same MC\ndomain) for upto 100ms, before picking up load from the overloaded\nCPU. Needless to say, this leads to increased scheduling latency for\ntasks, affecting performance adversely.\n\nBy setting MC domain's busy_factor value to 1, we limit maximum\ninterval that busy CPU can put off load balance checks to 4ms\n(effectively 10ms, given HZ value of 100).\n\nChange-Id: Id45869d06f5556ea8eec602b65c2ffd2143fe060\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/3133ab16329b802906f70083f4e33d19f95a69a3"},{"sha":"92102967de05d6d20e30a9794b1b31439df09d81","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>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/92102967de05d6d20e30a9794b1b31439df09d81"},{"sha":"222c76b0158cc04c6ce0a71894b281d11c57b5f4","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: If221afad7bc9b991f08cb26eec0efae715d8813d\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/AICP/kernel_google_msm/commits/222c76b0158cc04c6ce0a71894b281d11c57b5f4"},{"sha":"6f1d54e0cf00de05421f40db1702e4275f3906f2","author":{"email":"f2ad263351ded8bf8d0b90799bb8b9622c429cf8@gmail.com","name":"Zhao Wei Liew"},"message":"block: bfq: Default to IOPs mode on SSDs\n\nBased on the similar commit for CFQ.\n\nDisabling slice_idle improves throughput on SSDs.\n\nPreviously, we disabled slice_idle based on a prop set on boot. However,\nif/when the user switches schedulers, slice_idle gets set to 1 again.\nDisabling slice_idle in the kernel ensures that slice_idle is always\ndisabled.\n\nChange-Id: I84212289240b45967bc0c860fb22f586c1c6f5d5","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/6f1d54e0cf00de05421f40db1702e4275f3906f2"},{"sha":"88c81f6c26193564ec7ca0c8bac817702f904779","author":{"email":"d742c8926136147b41811902e91ce4bd1f5cc0f6@codeaurora.org","name":"Mahesh Sivasubramanian"},"message":"msm: rpm-smd: Configure WQ for higer priority\n\nWhen the workqueue runs at a lower priority, it gets starved by higher\npriority threads. Bump the WQ priority to high to ensure rpm smd work\nqueue gets a fair chance\n\nChange-Id: I06b864611cf45afe6931d6030327806032894663\nSigned-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/88c81f6c26193564ec7ca0c8bac817702f904779"},{"sha":"cb7077b34b23e5648fae9a1661dff95a94cb6989","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"block: Reserve only one queue tag for sync IO if only 3 tags are available\n\nIn case a device has three tags available we still reserve two of them\nfor sync IO. That leaves only a single tag for async IO such as\nwriteback from flusher thread which results in poor performance.\n\nAllow async IO to consume two tags in case queue has three tag availabe\nto get a decent async write performance.\n\nThis patch improves streaming write performance on a machine with such disk\nfrom ~21 MB/s to ~52 MB/s. Also postmark throughput in presence of\nstreaming writer improves from 8 to 12 transactions per second so sync\nIO doesn't seem to be harmed in presence of heavy async writer.\n\nChange-Id: I4b37f82c1fcf058369f1f93956f90cb92bd92f86\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/cb7077b34b23e5648fae9a1661dff95a94cb6989"},{"sha":"50d06d4e495333e359aad58eb767963ffbb1e6c8","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"writeback: fix occasional slow sync(1)\n\nIn case when system contains no dirty pages, wakeup_flusher_threads() will\nsubmit WB_SYNC_NONE writeback for 0 pages so wb_writeback() exits\nimmediately without doing anything, even though there are dirty inodes in\nthe system.  Thus sync(1) will write all the dirty inodes from a\nWB_SYNC_ALL writeback pass which is slow.\n\nFix the problem by using get_nr_dirty_pages() in wakeup_flusher_threads()\ninstead of calculating number of dirty pages manually.  That function also\ntakes number of dirty inodes into account.\n\nChange-Id: I191b6f45738dade63482e6c8a34a20dd96a4397a\nSigned-off-by: Jan Kara <jack@suse.cz>\nReported-by: Paul Taysom <taysom@chromium.org>\nCc: Wu Fengguang <fengguang.wu@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/50d06d4e495333e359aad58eb767963ffbb1e6c8"},{"sha":"5ef680bb65b01e98a81aa1872a11ef1d86224d51","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\nChange-Id: I4fdc35782a69cc3bc57213b541841f896665e44e\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>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/5ef680bb65b01e98a81aa1872a11ef1d86224d51"},{"sha":"88148a8371acb88877bf1da78c292bfaffb8f066","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\nChange-Id: I398651eb74d6f21c96cbe723040c66b3fca7bfec\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/88148a8371acb88877bf1da78c292bfaffb8f066"},{"sha":"5d7fabffc70e512ee355740c9d30e2ed44498b37","author":{"email":"2ffd0f418731020ea4d34ffb64140382adaee654@bull.net","name":"Sebastien Buisson"},"message":"fs/buffer.c: increase the buffer-head per-CPU LRU size\n\nIncrease the buffer-head per-CPU LRU size to allow efficient filesystem\noperations that access many blocks for each transaction.  For example,\ncreating a file in a large ext4 directory with quota enabled will access\nmultiple buffer heads and will overflow the LRU at the default 8-block LRU\nsize:\n\n* parent directory inode table block (ctime, nlinks for subdirs)\n* new inode bitmap\n* inode table block\n* 2 quota blocks\n* directory leaf block (not reused, but pollutes one cache entry)\n* 2 levels htree blocks (only one is reused, other pollutes cache)\n* 2 levels indirect/index blocks (only one is reused)\n\nThe buffer-head per-CPU LRU size is raised to 16, as it shows in metadata\nperformance benchmarks up to 10% gain for create, 4% for lookup and 7% for\ndestroy.\n\nChange-Id: Ib25a3dd32b13a16dd47339d864dc37f41c61ab8c\nSigned-off-by: Liang Zhen <liang.zhen@intel.com>\nSigned-off-by: Andreas Dilger <andreas.dilger@intel.com>\nSigned-off-by: Sebastien Buisson <sebastien.buisson@bull.net>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/5d7fabffc70e512ee355740c9d30e2ed44498b37"},{"sha":"6636dff3060d746f36d08c2a998cdbed1381a458","author":{"email":"fd4a61949a28ae8cdd740d5b4a7df30899289069@suse.cz","name":"Jiri Bohac"},"message":"timer: Prevent overflow in apply_slack\n\ncommit 98a01e779f3c66b0b11cd7e64d531c0e41c95762 upstream.\n\nOn architectures with sizeof(int) < sizeof (long), the\ncomputation of mask inside apply_slack() can be undefined if the\ncomputed bit is > 32.\n\nE.g. with: expires = 0xffffe6f5 and slack = 25, we get:\n\nexpires_limit = 0x20000000e\nbit = 33\nmask = (1 << 33) - 1  /* undefined */\n\nOn x86, mask becomes 1 and and the slack is not applied properly.\nOn s390, mask is -1, expires is set to 0 and the timer fires immediately.\n\nUse 1UL << bit to solve that issue.\n\nChange-Id: I81011b017e9d0ace0898b7be4d5ae173b69008d6\nSuggested-by: Deborah Townsend <dstownse@us.ibm.com>\nSigned-off-by: Jiri Bohac <jbohac@suse.cz>\nLink: http://lkml.kernel.org/r/20140418152310.GA13654@midget.suse.cz\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/6636dff3060d746f36d08c2a998cdbed1381a458"},{"sha":"d77821c01f989546faa28908356adfef1d96936c","author":{"email":"f34fa9a6ed7f70238faacc0289802dd5d831b64e@fb.com","name":"Calvin Owens"},"message":"ksoftirqd: Enable IRQs and call cond_resched() before poking RCU\n\ncommit 28423ad283d5348793b0c45cc9b1af058e776fd6 upstream.\n\nWhile debugging an issue with excessive softirq usage, I encountered the\nfollowing note in commit 3e339b5dae24a706 (\"softirq: Use hotplug thread\ninfrastructure\"):\n\n    [ paulmck: Call rcu_note_context_switch() with interrupts enabled. ]\n\n...but despite this note, the patch still calls RCU with IRQs disabled.\n\nThis seemingly innocuous change caused a significant regression in softirq\nCPU usage on the sending side of a large TCP transfer (~1 GB/s): when\nintroducing 0.01% packet loss, the softirq usage would jump to around 25%,\nspiking as high as 50%. Before the change, the usage would never exceed 5%.\n\nMoving the call to rcu_note_context_switch() after the cond_sched() call,\nas it was originally before the hotplug patch, completely eliminated this\nproblem.\n\nChange-Id: I2f110078e7424894aefb409c0842393607dacc5f\nSigned-off-by: Calvin Owens <calvinowens@fb.com>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nSigned-off-by: Mike Galbraith <mgalbraith@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/d77821c01f989546faa28908356adfef1d96936c"},{"sha":"85847ab244e05186965ed3f1338f5bb182b63a17","author":{"email":"433adf4e000ef006e7ed86a6a87b34fca89b9b00@samsung.com","name":"Anshul Garg"},"message":"Input: optimize events_per_packet count calculation\n\nThis patch avoids unnecessary operations while estimating events per\npacket for an input device when event type is not set.\n\nChange-Id: I913be1e5356d5ca7d3047e6b0413069993c2921c\nSigned-off-by: Anshul Garg <anshul.g@samsung.com>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nGit-commit: baf332c0f1cede26e9c2af6276b36b4c3a36e34a\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nSigned-off-by: Matt Wagantall <mattw@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/85847ab244e05186965ed3f1338f5bb182b63a17"},{"sha":"6e0eb41c0e1462557eadccc0d97b57a08800066a","author":{"email":"d91a346a9a76eb1627d34d097d6cb4c8e5067100@gmail.com","name":"Joonsoo Kim"},"message":"mm/slub: don't wait for high-order page allocation\n\nDescription is almost copied from commit fb05e7a89f50 (\"net: don't wait\nfor order-3 page allocation\").\n\nI saw excessive direct memory reclaim/compaction triggered by slub.  This\ncauses performance issues and add latency.  Slub uses high-order\nallocation to reduce internal fragmentation and management overhead.  But,\ndirect memory reclaim/compaction has high overhead and the benefit of\nhigh-order allocation can't compensate the overhead of both work.\n\nThis patch makes auxiliary high-order allocation atomic.  If there is no\nmemory pressure and memory isn't fragmented, the alloction will still\nsuccess, so we don't sacrifice high-order allocation's benefit here.  If\nthe atomic allocation fails, direct memory reclaim/compaction will not be\ntriggered, allocation fallback to low-order immediately, hence the direct\nmemory reclaim/compaction overhead is avoided.  In the allocation failure\ncase, kswapd is waken up and trying to make high-order freepages, so\nallocation could success next time.\n\nFollowing is the test to measure effect of this patch.\n\nSystem: QEMU, CPU 8, 512 MB\nMem: 25% memory is allocated at random position to make fragmentation.\n Memory-hogger occupies 150 MB memory.\nWorkload: hackbench -g 20 -l 1000\n\nAverage result by 10 runs (Base va Patched)\n\nelapsed_time(s): 4.3468 vs 2.9838\ncompact_stall: 461.7 vs 73.6\npgmigrate_success: 28315.9 vs 7256.1\n\nChange-Id: I84e305b4de4ce3c9d387c74d68a753fda4fe2234\nSigned-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Christoph Lameter <cl@linux.com>\nCc: Pekka Enberg <penberg@kernel.org>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: Shaohua Li <shli@fb.com>\nCc: Vlastimil Babka <vbabka@suse.cz>\nCc: Michal Hocko <mhocko@suse.cz>\nCc: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nGit-commit: 45eb00cd3a034b8448f52fd9074e9b2b11d857c1\nGit-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\nSigned-off-by: Liam Mark <lmark@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/6e0eb41c0e1462557eadccc0d97b57a08800066a"},{"sha":"e96061e438206a587f8a157838d1c93068b980c5","author":{"email":"542f19f65d99bf50d5e7d050ef18ac00c4fe000c@tencent.com","name":"Liu Yu"},"message":"tcp_cubic: fix the range of delayed_ack\n\n[ Upstream commit 0cda345d1b2201dd15591b163e3c92bad5191745 ]\n\ncommit b9f47a3aaeab (tcp_cubic: limit delayed_ack ratio to prevent\ndivide error) try to prevent divide error, but there is still a little\nchance that delayed_ack can reach zero. In case the param cnt get\nnegative value, then ratio+cnt would overflow and may happen to be zero.\nAs a result, min(ratio, ACK_RATIO_LIMIT) will calculate to be zero.\n\nIn some old kernels, such as 2.6.32, there is a bug that would\npass negative param, which then ultimately leads to this divide error.\n\ncommit 5b35e1e6e9c (tcp: fix tcp_trim_head() to adjust segment count\nwith skb MSS) fixed the negative param issue. However,\nit's safe that we fix the range of delayed_ack as well,\nto make sure we do not hit a divide by zero.\n\nChange-Id: Ida293e247f4dc5d4ffb64cd26e70f03c7ae2267e\nCC: Stephen Hemminger <shemminger@vyatta.com>\nSigned-off-by: Liu Yu <allanyuliu@tencent.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nAcked-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/e96061e438206a587f8a157838d1c93068b980c5"},{"sha":"0800de2daa49a40991102d8efc8da8b84093a27c","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"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/AICP/kernel_google_msm/commits/0800de2daa49a40991102d8efc8da8b84093a27c"},{"sha":"7a83455823e2463f37a53b4e6facf08a27c94a74","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"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/AICP/kernel_google_msm/commits/7a83455823e2463f37a53b4e6facf08a27c94a74"},{"sha":"7645648b8ae16152fe62bffd5c2fe9c0eec2d02c","author":{"email":"f2ad263351ded8bf8d0b90799bb8b9622c429cf8@gmail.com","name":"Zhao Wei Liew"},"message":"Revert \"cpufreq: ondemand: Remove unused waitqueue\"\n\nThis reverts commit e53de1c0723955a194246660beb12f9ad8d9cb14.\n\nChange-Id: I1c7f24c6e42305df17f9d7b79519911b4c80e4aa","distinct":true,"url":"https://api.github.com/repos/AICP/kernel_google_msm/commits/7645648b8ae16152fe62bffd5c2fe9c0eec2d02c"}]}