{"push_id":984775345,"size":9,"distinct_size":9,"ref":"refs/heads/cm-13.0-rebase","head":"b1769b9a515a549a5d91794c75bdad9833c1cad8","before":"2aaa01dff53239e747cb34bebe4a04bfca331a0d","commits":[{"sha":"fa757be6f82514ff49e09fdf09707fe78a547cff","author":{"email":"9ae2fff1e81f4043f3b3adb9ed5eedbbd34e3953@codeaurora.org","name":"Lee Susman"},"message":"mm: change initial readahead window size calculation\n\nChange the logic which determines the initial readahead window size\nsuch that for small requests (one page) the initial window size\nwill be x4 the size of the original request, regardless of the\nVM_MAX_READAHEAD value. This prevents a rapid ramp-up\nthat could be caused due to increasing VM_MAX_READAHEAD.\n\nChange-Id: I93d59c515d7e6c6d62348790980ff7bd4f434997\nSigned-off-by: Lee Susman <lsusman@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/fa757be6f82514ff49e09fdf09707fe78a547cff"},{"sha":"a04c518254bbac271d7c97161469e31b425d55f3","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>\n\nChange-Id: I9e55d65f5ecb2305497711d4688f0647d9346035","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/a04c518254bbac271d7c97161469e31b425d55f3"},{"sha":"9856aed743d4475407e274c5091072f905ec6f6e","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"softirq: reduce latencies\n\ncommit c10d73671ad30f54692f7f69f0e09e75d3a8926a upstream.\n\nIn various network workloads, __do_softirq() latencies can be up\nto 20 ms if HZ=1000, and 200 ms if HZ=100.\n\nThis is because we iterate 10 times in the softirq dispatcher,\nand some actions can consume a lot of cycles.\n\nThis patch changes the fallback to ksoftirqd condition to :\n\n- A time limit of 2 ms.\n- need_resched() being set on current task\n\nWhen one of this condition is met, we wakeup ksoftirqd for further\nsoftirq processing if we still have pending softirqs.\n\nUsing need_resched() as the only condition can trigger RCU stalls,\nas we can keep BH disabled for too long.\n\nI ran several benchmarks and got no significant difference in\nthroughput, but a very significant reduction of latencies (one order\nof magnitude) :\n\nIn following bench, 200 antagonist \"netperf -t TCP_RR\" are started in\nbackground, using all available cpus.\n\nThen we start one \"netperf -t TCP_RR\", bound to the cpu handling the NIC\nIRQ (hard+soft)\n\nBefore patch :\n\nRT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY\nMIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET\nto 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind\nRT_LATENCY=550110.424\nMIN_LATENCY=146858\nMAX_LATENCY=997109\nP50_LATENCY=305000\nP90_LATENCY=550000\nP99_LATENCY=710000\nMEAN_LATENCY=376989.12\nSTDDEV_LATENCY=184046.92\n\nAfter patch :\n\nRT_LATENCY,MIN_LATENCY,MAX_LATENCY,P50_LATENCY,P90_LATENCY,P99_LATENCY,MEAN_LATENCY,STDDEV_LATENCY\nMIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET\nto 7.7.7.84 () port 0 AF_INET : first burst 0 : cpu bind\nRT_LATENCY=40545.492\nMIN_LATENCY=9834\nMAX_LATENCY=78366\nP50_LATENCY=33583\nP90_LATENCY=59000\nP99_LATENCY=69000\nMEAN_LATENCY=38364.67\nSTDDEV_LATENCY=12865.26\n\nChange-Id: I94f96a9040a018644d3e2150f54acfd9a080992d\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: David Miller <davem@davemloft.net>\nCc: Tom Herbert <therbert@google.com>\nCc: Ben Hutchings <bhutchings@solarflare.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\n[xr: Backported to 3.4: Adjust context]\nSigned-off-by: Rui Xiang <rui.xiang@huawei.com>\nSigned-off-by: Zefan Li <lizefan@huawei.com>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/9856aed743d4475407e274c5091072f905ec6f6e"},{"sha":"faa2bae52fb484ba94f2b892b03112080834f195","author":{"email":"e203ad089043f59502b8a6bd676687433f467ba0@motorola.com","name":"Chris Fries"},"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\nChange-Id: I5e7605d4fb5c8492cfe7a73629d0d0ce7afd1f37\nSigned-off-by: Chris Fries <C.Fries@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/526804\nSLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Igor Kovalenko <cik009@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/faa2bae52fb484ba94f2b892b03112080834f195"},{"sha":"21192bc1aaa80856b5c0d108a16e79b36c02bb13","author":{"email":"fdd63d6d2cf1fcca4a32e9bdba550776ff3f9f3c@motorola.com","name":"Hong-Mei Li"},"message":"arm: lib: Fix makefile issue\n\nFix the typo introduced by commit fb7051a183cba3925f1f00c9bdadc2adcc682020.\n\nChange-Id: Ia23c80f903ed431e60e4ba17c9c6d527e6febd87\nSigned-off-by: Hong-Mei Li <a21834@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/527915\nSLT-Approved: Gerrit Code Review <gerrit-blurdev@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Christopher Fries <qcf001@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/21192bc1aaa80856b5c0d108a16e79b36c02bb13"},{"sha":"5ebcd6029a4b287cfb2a7fb54aefac1458aa9826","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/zwliew/android_kernel_asus_flo/commits/5ebcd6029a4b287cfb2a7fb54aefac1458aa9826"},{"sha":"ca47c78839c4f6ee4ceeddaee04b9369104186e6","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/zwliew/android_kernel_asus_flo/commits/ca47c78839c4f6ee4ceeddaee04b9369104186e6"},{"sha":"baaad18c58a6e20ac770fd1d5a86e1247151aeca","author":{"email":"94eba8fd98e2bd828100ff2a58b7802ee6f84789@codeaurora.org","name":"Narayanan Gopalakrishnan"},"message":"msm: cpufreq: increase priority of thread that increases frequencies\n\nWhen the cpufreq governors request for increase in frequency from kworker\nthreads, there is chance that the kworker thread is cpu starved due to\nother high priority threads, leading to undesirable increase in frequency\nramp-up latency. Add the calling thread to SCHED_FIFO policy when\nrequesting for increase in frequency and restore back to original policy\nafter ramp-up is completed.\n\nChange-Id: Ie4fa199b7f9087717cb94dfcc2eddea27cc0012b\nSigned-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/baaad18c58a6e20ac770fd1d5a86e1247151aeca"},{"sha":"b1769b9a515a549a5d91794c75bdad9833c1cad8","author":{"email":"03c7ab1ecfdb127a25ce2b4e2919a11a14c36b4f@codeaurora.org","name":"Michael Bohan"},"message":"msm: rpm-smd: Fix memory leak on free_request\n\nAfter acknowledging a transaction, all buffers previously\nallocated must be properly freed.\n\nCRs-fixed: 401535\nChange-Id: I70488357ccd32a1ce8c212f3cb0077aa502687c6\nSigned-off-by: Michael Bohan <mbohan@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/zwliew/android_kernel_asus_flo/commits/b1769b9a515a549a5d91794c75bdad9833c1cad8"}]}