{"push_id":985815949,"size":52,"distinct_size":52,"ref":"refs/heads/main","head":"68e82ea57f06176559315e578485360f9c694542","before":"a44376086aad5ea336cb1ee7698a97fc315c3a74","commits":[{"sha":"15344bd18a351ce60ec6bf863ec580591d555627","author":{"email":"3807cf899f217da549814bf6c330d3b6e6819ccf@gmail.com","name":"Akinobu Mita"},"message":"block_dev: implement readpages() to optimize sequential read\n\nSequential read from a block device is expected to be equal or faster than\nfrom the file on a filesystem.  But it is not correct due to the lack of\neffective readpages() in the address space operations for block device.\n\nThis implements readpages() operation for block device by using\nmpage_readpages() which can create multipage BIOs instead of BIOs for each\npage and reduce system CPU time consumption.\n\nInstall 1GB of RAM disk storage:\n\n\t# modprobe scsi_debug dev_size_mb=1024 delay=0\n\nSequential read from file on a filesystem:\n\n\t# mkfs.ext4 /dev/$DEV\n\t# mount /dev/$DEV /mnt\n\t# fio --name=t --size=512m --rw=read --filename=/mnt/file\n\t...\n\t  read : io=524288KB, bw=2133.4MB/s, iops=546133, runt=   240msec\n\nSequential read from a block device:\n\t# fio --name=t --size=512m --rw=read --filename=/dev/$DEV\n\t...\n(Without this commit)\n\t  read : io=524288KB, bw=1700.2MB/s, iops=435455, runt=   301msec\n\n(With this commit)\n\t  read : io=524288KB, bw=2160.4MB/s, iops=553046, runt=   237msec\n\nSigned-off-by: Akinobu Mita <akinobu.mita@gmail.com>\nCc: Jens Axboe <axboe@kernel.dk>\nCc: Alexander Viro <viro@zeniv.linux.org.uk>\nCc: Jeff Moyer <jmoyer@redhat.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/leekindo/android_kernel_oneplus_msm8974/commits/15344bd18a351ce60ec6bf863ec580591d555627"},{"sha":"383f3493847bce6fc67419f61401a6237d472963","author":{"email":"f35204f44eabfe97bbcdd18aee9e9fffc59f29e1@redhat.com","name":"Doug Ledford"},"message":"ipc/mqueue: improve performance of send/recv\n\nThe existing implementation of the POSIX message queue send and recv\nfunctions is, well, abysmal.  Even worse than abysmal.  I submitted a\npatch to increase the maximum POSIX message queue limit to 65536 due to\ncustomer needs, however, upon looking over the send/recv implementation, I\nrealized that my customer needs help with that too even if they don't know\nit.  The basic problem is that, given the fairly typical use case scenario\nfor a large queue of queueing lots of messages all at the same priority (I\nverified with my customer that this is indeed what their app does), the\nmsg_insert routine is basically a frikkin' bubble sort.  I mean, whoa,\nthat's *so* middle school.\n\nOK, OK, to not slam the original author too much, I'm sure they didn't\nenvision a queue depth of 50,000+ messages.  No one would think that\nmoving elements in an array, one at a time, and dereferencing each pointer\nin that array to check priority of the message being pointed too, again\none at a time, for 50,000+ times would be good.  So let's assume that, as\nis typical, the users have found a way to break our code simply by using\nit in a way we didn't envision.  Fair enough.\n\n\"So, just how broken is it?\", you ask.  I wondered the same thing, so I\nwrote an app to let me know.  It's my next patch.  It gave me some\ninteresting results.  Here's what it tested:\n\nInterference with other apps - In continuous mode, the app just sits there\nand hits a message queue forever, while you go do something productive on\nanother terminal using other CPUs.  You then measure how long it takes you\nto do that something productive.  Then you restart the app in fake\ncontinuous mode, and it sits in a tight loop on a CPU while you repeat\nyour tests.  The whole point of this is to keep one CPU tied up (so it\ncan't be used in your other work) but in one case tied up hitting the\nmqueue code so we can see the effect of walking that 65,528 element array\none pointer at a time on the global CPU cache.  If it's bad, then it will\nslow down your app on the other CPUs just by polluting cache mercilessly.\nIn the fake case, it will be in a tight loop, but not polluting cache.\nTesting the mqueue subsystem directly - Here we just run a number of tests\nto see how the mqueue subsystem performs under different conditions.  A\ncouple conditions are known to be worst case for the old system, and some\nroutines, so this tests all of them.\n\nSo, on to the results already:\n\nSubsystem/Test                  Old                         New\n\nTime to compile linux\nkernel (make -j12 on a\n6 core CPU)\n  Running mqueue test     user 49m10.744s             user 45m26.294s\n\t\t\t   sys  5m51.924s              sys  4m59.894s\n\t\t\t total 55m02.668s            total 50m26.188s\n\n  Running fake test       user 45m32.686s             user 45m18.552s\n                           sys  5m12.465s              sys  4m56.468s\n                         total 50m45.151s            total 50m15.020s\n\n  % slowdown from mqueue\n    cache thrashing            ~8%                         ~.5%\n\nAvg time to send/recv (in nanoseconds per message)\n  when queue empty            305/288                    349/318\n  when queue full (65528 messages)\n    constant priority      526589/823                    362/314\n    increasing priority    403105/916                    495/445\n    decreasing priority     73420/594                    482/409\n    random priority        280147/920                    546/436\n\nTime to fill/drain queue (65528 messages, in seconds)\n  constant priority         17.37/.12                    .13/.12\n  increasing priority        4.14/.14                    .21/.18\n  decreasing priority       12.93/.13                    .21/.18\n  random priority            8.88/.16                    .22/.17\n\nSo, I think the results speak for themselves.  It's possible this\nimplementation could be improved by cacheing at least one priority level\nin the node tree (that would bring the queue empty performance more in\nline with the old implementation), but this works and is *so* much better\nthan what we had, especially for the common case of a single priority in\nuse, that further refinements can be in follow on patches.\n\n[akpm@linux-foundation.org: fix typo in comment, remove stray semicolon]\n[levinsasha928@gmail.com: use correct gfp flags in msg_insert]\nSigned-off-by: Doug Ledford <dledford@redhat.com>\nCc: Stephen Rothwell <sfr@canb.auug.org.au>\nCc: Manfred Spraul <manfred@colorfullife.com>\nAcked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>\nSigned-off-by: Sasha Levin <levinsasha928@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\n\nConflicts:\n\tipc/mqueue.c","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/383f3493847bce6fc67419f61401a6237d472963"},{"sha":"ad92b7534735342950371aa095b4980fcf00bf65","author":{"email":"312c7d941f03386814be517ffdb3e0eb6624e275@google.com","name":"Eric Dumazet"},"message":"af_unix: speedup /proc/net/unix\n\n/proc/net/unix has quadratic behavior, and can hold unix_table_lock for\na while if high number of unix sockets are alive. (90 ms for 200k\nsockets...)\n\nWe already have a hash table, so its quite easy to use it.\n\nProblem is unbound sockets are still hashed in a single hash slot\n(unix_socket_table[UNIX_HASH_TABLE])\n\nThis patch also spreads unbound sockets to 256 hash slots, to speedup\nboth /proc/net/unix and unix_diag.\n\nTime to read /proc/net/unix with 200k unix sockets :\n(time dd if=/proc/net/unix of=/dev/null bs=4k)\n\nbefore : 520 secs\nafter : 2 secs\n\nChange-Id: I5806cd54f6f8844d2c88e58d8245ebcc1d898b18\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Steven Whitehouse <swhiteho@redhat.com>\nCc: Pavel Emelyanov <xemul@parallels.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/ad92b7534735342950371aa095b4980fcf00bf65"},{"sha":"f9d7654f9109db258c243f007635052f20b886f1","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"ext4: Speedup WB_SYNC_ALL pass called from sync(2)\n\nWhen doing filesystem wide sync, there's no need to force transaction\ncommit (or synchronously write inode buffer) separately for each inode\nbecause ext4_sync_fs() takes care of forcing commit at the end (VFS\ntakes care of flushing buffer cache, respectively). Most of the time\nthis slowness doesn't manifest because previous WB_SYNC_NONE writeback\ndoesn't leave much to write but when there are processes aggressively\ncreating new files and several filesystems to sync, the sync slowness\ncan be noticeable. In the following test script sync(1) takes around 6\nminutes when there are two ext4 filesystems mounted on a standard SATA\ndrive. After this patch sync takes a couple of seconds so we have about\ntwo orders of magnitude improvement.\n\n      function run_writers\n      {\n        for (( i = 0; i < 10; i++ )); do\n          mkdir $1/dir$i\n          for (( j = 0; j < 40000; j++ )); do\n            dd if=/dev/zero of=$1/dir$i/$j bs=4k count=4 &>/dev/null\n          done &\n        done\n      }\n\n      for dir in \"$@\"; do\n        run_writers $dir\n      done\n\n      sleep 40\n      time sync\n\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/f9d7654f9109db258c243f007635052f20b886f1"},{"sha":"53144f8faaa82a5b36b78411e6ba52a7165e165e","author":{"email":"749e12e18869a210449c40d360fd34eba62d827d@gmail.com","name":"Jorge Ayres Pereira"},"message":"Enable UNALIGNED_ACCESS, this will actually improve kernel performance.","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/53144f8faaa82a5b36b78411e6ba52a7165e165e"},{"sha":"10831b525597f1b17814f7af7c4a81ba299b19d9","author":{"email":"24f7fe9d205c8a9f6ade0c2894e14303ca16087f@intel.com","name":"Fengguang Wu"},"message":"readahead: make context readahead more conservative\n\nThis helps performance on moderately dense random reads on SSD.\n\nTransaction-Per-Second numbers provided by Taobao:\n\n\t\tQPS\tcase\n\t\t-------------------------------------------------------\n\t\t7536\tdisable context readahead totally\nw/ patch:\t7129\tslower size rampup and start RA on the 3rd read\n\t\t6717\tslower size rampup\nw/o patch:\t5581\tunmodified context readahead\n\nBefore, readahead will be started whenever reading page N+1 when it happen\nto read N recently.  After patch, we'll only start readahead when *three*\nrandom reads happen to access pages N, N+1, N+2.  The probability of this\nhappening is extremely low for pure random reads, unless they are very\ndense, which actually deserves some readahead.\n\nAlso start with a smaller readahead window.  The impact to interleaved\nsequential reads should be small, because for a long run stream, the the\nsmall readahead window rampup phase is negletable.\n\nThe context readahead actually benefits clustered random reads on HDD\nwhose seek cost is pretty high.  However as SSD is increasingly used for\nrandom read workloads it's better for the context readahead to concentrate\non interleaved sequential reads.\n\nAnother SSD rand read test from Miao\n\n        # file size:        2GB\n        # read IO amount: 625MB\n        sysbench --test=fileio          \\\n                --max-requests=10000    \\\n                --num-threads=1         \\\n                --file-num=1            \\\n                --file-block-size=64K   \\\n                --file-test-mode=rndrd  \\\n                --file-fsync-freq=0     \\\n                --file-fsync-end=off    run\n\nshows the performance of btrfs grows up from 69MB/s to 121MB/s, ext4 from\n104MB/s to 121MB/s.\n\nSigned-off-by: Wu Fengguang <fengguang.wu@intel.com>\nTested-by: Tao Ma <tm@tao.ma>\nTested-by: Miao Xie <miaox@cn.fujitsu.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/10831b525597f1b17814f7af7c4a81ba299b19d9"},{"sha":"99b65e20ddfec28403dd324a753cfacc6c2a0242","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\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/99b65e20ddfec28403dd324a753cfacc6c2a0242"},{"sha":"356fc3b6452e1d983cb7f323d534ded81ee0130a","author":{"email":"65d484aa1efdaf0ae258f87a04ed8ec8685cba3e@samsung.com","name":"Namjae Jeon"},"message":"writeback: fix writeback cache thrashing\n\nFrom: Namjae Jeon <namjae.jeon@samsung.com>\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: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/356fc3b6452e1d983cb7f323d534ded81ee0130a"},{"sha":"ced3143df2762205434ab2463dd6be7860abe474","author":{"email":"5b23f8226e886b22344fc642373ea657dd596b63@linux.vnet.ibm.com","name":"Srivatsa S. Bhat"},"message":"CPU hotplug, writeback: Don't call writeback_set_ratelimit() too often during hotplug\n\nThe CPU hotplug callback related to writeback calls writeback_set_ratelimit()\nduring every state change in the hotplug sequence. This is unnecessary\nsince num_online_cpus() changes only once during the entire hotplug operation.\n\nSo invoke the function only once per hotplug, thereby avoiding the\nunnecessary repetition of those costly calculations.\n\nSigned-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/ced3143df2762205434ab2463dd6be7860abe474"},{"sha":"fa393615f7a253c001042478ab0aeff7cd64871f","author":{"email":"331be22c6b63ca3e0a03d408c2d906b1b02cd5f2@cmpxchg.org","name":"Johannes Weiner"},"message":"mm/page-writeback.c: fix dirty_balance_reserve subtraction from dirtyable memory\n\nTejun reported stuttering and latency spikes on a system where random\ntasks would enter direct reclaim and get stuck on dirty pages.  Around\n50% of memory was occupied by tmpfs backed by an SSD, and another disk\n(rotating) was reading and writing at max speed to shrink a partition.\n\n: The problem was pretty ridiculous.  It's a 8gig machine w/ one ssd and 10k\n: rpm harddrive and I could reliably reproduce constant stuttering every\n: several seconds for as long as buffered IO was going on on the hard drive\n: either with tmpfs occupying somewhere above 4gig or a test program which\n: allocates about the same amount of anon memory.  Although swap usage was\n: zero, turning off swap also made the problem go away too.\n:\n: The trigger conditions seem quite plausible - high anon memory usage w/\n: heavy buffered IO and swap configured - and it's highly likely that this\n: is happening in the wild too.  (this can happen with copying large files\n: to usb sticks too, right?)\n\nThis patch (of 2):\n\nThe dirty_balance_reserve is an approximation of the fraction of free\npages that the page allocator does not make available for page cache\nallocations.  As a result, it has to be taken into account when\ncalculating the amount of \"dirtyable memory\", the baseline to which\ndirty_background_ratio and dirty_ratio are applied.\n\nHowever, currently the reserve is subtracted from the sum of free and\nreclaimable pages, which is non-sensical and leads to erroneous results\nwhen the system is dominated by unreclaimable pages and the\ndirty_balance_reserve is bigger than free+reclaimable.  In that case, at\nleast the already allocated cache should be considered dirtyable.\n\nFix the calculation by subtracting the reserve from the amount of free\npages, then adding the reclaimable pages on top.\n\n[akpm@linux-foundation.org: fix CONFIG_HIGHMEM build]\nSigned-off-by: Johannes Weiner <hannes@cmpxchg.org>\nReported-by: Tejun Heo <tj@kernel.org>\nTested-by: Tejun Heo <tj@kernel.org>\nReviewed-by: Rik van Riel <riel@redhat.com>\nCc: Mel Gorman <mgorman@suse.de>\nCc: Wu Fengguang <fengguang.wu@intel.com>\nReviewed-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/leekindo/android_kernel_oneplus_msm8974/commits/fa393615f7a253c001042478ab0aeff7cd64871f"},{"sha":"48491e191293c85e843ed31e78332c07525993f2","author":{"email":"8d0fc11caeb4659419f0ba3104eb4a9d30848d42@canonical.com","name":"Ming Lei"},"message":"block/partitions: optimize memory allocation in check_partition()\n\nCurrently, sizeof(struct parsed_partitions) may be 64KB in 32bit arch, so\nit is easy to trigger page allocation failure by check_partition,\nespecially in hotplug block device situation(such as, USB mass storage,\nMMC card, ...), and Felipe Balbi has observed the failure.\n\nThis patch does below optimizations on the allocation of struct\nparsed_partitions to try to address the issue:\n\n- make parsed_partitions.parts as pointer so that the pointed memory can\n  fit in 32KB buffer, then approximate 32KB memory can be saved\n\n- vmalloc the buffer pointed by parsed_partitions.parts because 32KB is\n  still a bit big for kmalloc\n\n- given that many devices have the partition count limit, so only\n  allocate disk_max_parts() partitions instead of 256 partitions always\n\nSigned-off-by: Ming Lei <ming.lei@canonical.com>\nReported-by: Felipe Balbi <balbi@ti.com>\nCc: Jens Axboe <axboe@kernel.dk>\nReviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>\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>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/48491e191293c85e843ed31e78332c07525993f2"},{"sha":"37c517a9425fdc1551d1feb398f79794ec7a0fb8","author":{"email":"749e12e18869a210449c40d360fd34eba62d827d@gmail.com","name":"Jorge Ayres Pereira"},"message":"bcmdhd: reduce to 250ms\n\nSigned-off-by: YoshiShaPow <yoshipga@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/37c517a9425fdc1551d1feb398f79794ec7a0fb8"},{"sha":"f676787bfca8d362fc9db9c83254f3743c50c616","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"sound: add sound control to increase headphones, speaker and mic gain.\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nsound: wcd9320: tidy up things a little bit. Only accept signed values from now on. The 'headset gain' will only be used to remove some gain noise, increasing it beyond 1 step above the default doesn't make a difference so rather just have it decrease the gain.\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nsound: wcd9320: implement separate locks to prevent derps\n\n* playback, speaker and record locks only to the changed\nregister values, we don't need the locks to go through other\nregisters\n* this fixes a bug where a user adjusted the headphones gain\nand speaker and/or mic would stop working because the lock was\nenabled and the switch case would return earlier than it should\n* qualcomm, up yours\n\nChange-Id: I851d10a829e0066082e4b139e58c9848066439b6\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/f676787bfca8d362fc9db9c83254f3743c50c616"},{"sha":"0d3ff2d8e91a33049195f5ee28482174218babc3","author":{"email":"85e533f2e78486213c4d69f71462342ec0c62734@redhat.com","name":"Mike Snitzer"},"message":"block: disable entropy contributions for nonrot devices\n\nClear QUEUE_FLAG_ADD_RANDOM in all block drivers that set\nQUEUE_FLAG_NONROT.\n\nHistorically, all block devices have automatically made entropy\ncontributions.  But as previously stated in commit e2e1a148 (\"block: add\nsysfs knob for turning off disk entropy contributions\"):\n    - On SSD disks, the completion times aren't as random as they\n      are for rotational drives. So it's questionable whether they\n      should contribute to the random pool in the first place.\n    - Calling add_disk_randomness() has a lot of overhead.\n\nThere are more reliable sources for randomness than non-rotational block\ndevices.  From a security perspective it is better to err on the side of\ncaution than to allow entropy contributions from unreliable \"random\"\nsources.\n\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\n\nConflicts:\n\tdrivers/block/nbd.c\n\tdrivers/block/null_blk.c\n\tdrivers/block/nvme-core.c\n\tdrivers/block/rsxx/dev.c\n\tdrivers/block/skd_main.c\n\tdrivers/block/zram/zram_drv.c\n\tdrivers/md/bcache/super.c\n\tdrivers/s390/block/scm_blk.c\n\tdrivers/s390/block/xpram.c\n\nChange-Id: I733f051d20a48f2afce68b7113fd9f1261be430b","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/0d3ff2d8e91a33049195f5ee28482174218babc3"},{"sha":"274261935e0836ec393f469ff4251e8ec4b00be1","author":{"email":"895de8eefe3235903fd7778794b8e518edbaf8c7@gmail.com","name":"silasje1"},"message":"Sync with KitKat charge standard 3000mah battery\n\nyangfangbiao@oneplus.cn, 2015/01/06  Add for  sync with KK charge standard\n\nChange-Id: If53d083906db7abb29de9ea40e36ddc17ab02851","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/274261935e0836ec393f469ff4251e8ec4b00be1"},{"sha":"9c61fdfa2701e272dd21b0da54da002c00bad34a","author":{"email":"895de8eefe3235903fd7778794b8e518edbaf8c7@gmail.com","name":"Silas Arentsen"},"message":"Update QCOM charger values from OPPO source\n\nGot the DTS files per message. Can send files if needed.\n\nChange-Id: I080b3f1a72e30e9bbdde6e8f51e7b3564d106de9","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/9c61fdfa2701e272dd21b0da54da002c00bad34a"},{"sha":"facebf1f1c37b2585b9f78619f8f9482809942c1","author":{"email":"eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","name":"Vincent Guittot"},"message":"ARM: 7462/1: topology: factorize the update of sibling masks\n\nThis factorization has also been proposed in another patch that has not been\nmerged yet:\nhttp://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/080873.html\nSo, this patch could be dropped depending of the state of the other one.\n\nSigned-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>\nSigned-off-by: Vincent Guittot <vincent.guittot@linaro.org>\nReviewed-by: Namhyung Kim <namhyung@kernel.org>\nAcked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Jake Weinstein <xboxlover360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/facebf1f1c37b2585b9f78619f8f9482809942c1"},{"sha":"e147032b0ad6feaccd50a4722f3540fdb12d8368","author":{"email":"eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","name":"Vincent Guittot"},"message":"ARM: 7463/1: topology: Update cpu_power according to DT information\n\nUse cpu compatibility field and clock-frequency field of DT to\nestimate the capacity of each core of the system and to update\nthe cpu_power field accordingly.\nThis patch enables to put more running tasks on big cores than\non LITTLE ones. But this patch doesn't ensure that long running\ntasks will run on big cores and short ones on LITTLE cores.\n\nSigned-off-by: Vincent Guittot <vincent.guittot@linaro.org>\nReviewed-by: Namhyung Kim <namhyung@kernel.org>\nAcked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Jake Weinstein <xboxlover360@gmail.com>\n\nConflicts:\n\tarch/arm/kernel/topology.c","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/e147032b0ad6feaccd50a4722f3540fdb12d8368"},{"sha":"8976674f072286e7c7249858126231d0b3ce769f","author":{"email":"e5433cb8ec0d347bc3697f245ffa1ec71043e3af@ti.com","name":"Venkatraman Sathiyamoorthy"},"message":"ARM: 7482/1: topology: fix section mismatch warning for init_cpu_topology\n\nGet rid of this warning..\narch/arm/kernel/built-in.o(.text+0xac78): Section mismatch in reference\nfrom the function init_cpu_topology() to the function\n .init.text:parse_dt_topology()\nThe function init_cpu_topology() references\nthe function __init parse_dt_topology().\nThis is often because init_cpu_topology lacks a __init\nannotation or the annotation of parse_dt_topology is wrong.\n\nSigned-off-by: Venkatraman S <svenkatr@ti.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Jake Weinstein <xboxlover360@gmail.com>","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/8976674f072286e7c7249858126231d0b3ce769f"},{"sha":"29ccfeaaf9ced769f6ab33181324253ad0d0cb70","author":{"email":"b07d7e22a002c36e256b78f51f1f0db608e62a13@arm.com","name":"Lorenzo Pieralisi"},"message":"ARM: kernel: enhance MPIDR macro definitions\n\nKernel subsystems other than the topology layer need the MPIDR\nmask definitions to access the MPIDR without relying on hardcoded\nmasks. This patch moves the MPIDR register masks definition to\na header file and defines a macro to simplify access to MPIDR bit fields\nrepresenting affinity levels.\n\nSigned-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>\nAcked-by: Will Deacon <will.deacon@arm.com>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Jake Weinstein <xboxlover360@gmail.com>\n\nConflicts:\n\tarch/arm/kernel/topology.c","distinct":true,"url":"https://api.github.com/repos/leekindo/android_kernel_oneplus_msm8974/commits/29ccfeaaf9ced769f6ab33181324253ad0d0cb70"}]}