GitHub PushEvent at 2014-07-19 12:02:34
Repository: android_kernel_samsung_jf
Actor: Evisceration
Payload: {"shas":[["9bf9ce215c975a0e886f0aa4c94478f4a8a71f15","00e4cf8f46a57000a44449bf9dd8cbbcc209fd2a@linutronix.de","rcu: Yield simpler\n\nThe rcu_yield() code is amazing. It's there to avoid starvation of the\nsystem when lots of (boosting) work is to be done.\n\nNow looking at the code it's functionality is:\n\n Make the thread SCHED_OTHER and very nice, i.e. get it out of the way\n Arm a timer with 2 ticks\n schedule()\n\nNow if the system goes idle the rcu task returns, regains SCHED_FIFO\nand plugs on. If the systems stays busy the timer fires and wakes a\nper node kthread which in turn makes the per cpu thread SCHED_FIFO and\nbrings it back on the cpu. For the boosting thread the \"make it FIFO\"\nbit is missing and it just runs some magic boost checks. Now this is a\nlot of code with extra threads and complexity.\n\nIt's way simpler to let the tasks when they detect overload schedule\naway for 2 ticks and defer the normal wakeup as long as they are in\nyielded state and the cpu is not idle.\n\nThat solves the same problem and the only difference is that when the\ncpu goes idle it's not guaranteed that the thread returns right away,\nbut it won't be longer out than two ticks, so no harm is done. If\nthat's an issue than it is way simpler just to wake the task from\nidle as RCU has callbacks there anyway.\n\nChange-Id: Iea2933bc34aa2b0363e3ddb57402b7badb4e3cfa\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>\nCc: Rusty Russell <rusty@rustcorp.com.au>\nCc: Namhyung Kim <namhyung@kernel.org>\nReviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nLink: http://lkml.kernel.org/r/20120716103948.131256723@linutronix.de\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>","Thomas Gleixner",true],["b31d1a727d2311fab0aab34d82917a0a3f16da22","aaf6fd97230863eae371b8b6c4c40693d5d84b30@bynet.co.il","Always set noatime nodiratime on all partitions\n\nChange-Id: I8115c05cd1634d1b37879dcf616589c158000633","dorimanx",true],["5b6f5332f89b56fe55d5246e07bbb57ee6cd3d4b","20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","introduce for_each_thread() to replace the buggy while_each_thread()\n\nwhile_each_thread() and next_thread() should die, almost every lockless\nusage is wrong.\n\n1. Unless g == current, the lockless while_each_thread() is not safe.\n\n   while_each_thread(g, t) can loop forever if g exits, next_thread()\n   can't reach the unhashed thread in this case. Note that this can\n   happen even if g is the group leader, it can exec.\n\n2. Even if while_each_thread() itself was correct, people often use\n   it wrongly.\n\n   It was never safe to just take rcu_read_lock() and loop unless\n   you verify that pid_alive(g) == T, even the first next_thread()\n   can point to the already freed/reused memory.\n\nThis patch adds signal_struct->thread_head and task->thread_node to\ncreate the normal rcu-safe list with the stable head.  The new\nfor_each_thread(g, t) helper is always safe under rcu_read_lock() as\nlong as this task_struct can't go away.\n\nNote: of course it is ugly to have both task_struct->thread_node and the\nold task_struct->thread_group, we will kill it later, after we change\nthe users of while_each_thread() to use for_each_thread().\n\nPerhaps we can kill it even before we convert all users, we can\nreimplement next_thread(t) using the new thread_head/thread_node.  But\nwe can't do this right now because this will lead to subtle behavioural\nchanges.  For example, do/while_each_thread() always sees at least one\ntask, while for_each_thread() can do nothing if the whole thread group\nhas died.  Or thread_group_empty(), currently its semantics is not clear\nunless thread_group_leader(p) and we need to audit the callers before we\ncan change it.\n\nSo this patch adds the new interface which has to coexist with the old\none for some time, hopefully the next changes will be more or less\nstraightforward and the old one will go away soon.\n\nChange-Id: Ia6a6ed6c37ce9fca6684a03280b7be1514b90999\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nReviewed-by: Sergey Dyasly <dserrg@gmail.com>\nTested-by: Sergey Dyasly <dserrg@gmail.com>\nReviewed-by: Sameer Nanda <snanda@chromium.org>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nCc: Mandeep Singh Baines <msb@chromium.org>\nCc: \"Ma, Xindong\" <xindong.ma@intel.com>\nCc: Michal Hocko <mhocko@suse.cz>\nCc: \"Tu, Xiaobing\" <xiaobing.tu@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>","Oleg Nesterov",true],["61c0643089d23e56809897241702e30802e26da8","aa00819e304141d872f2e4b1c4be422ea3abbfe1@calxeda.com","ARM: 7587/1: implement optimized percpu variable access\n\nUse the previously unused TPIDRPRW register to store percpu offsets.\nTPIDRPRW is only accessible in PL1, so it can only be used in the kernel.\n\nThis replaces 2 loads with a mrc instruction for each percpu variable\naccess. With hackbench, the performance improvement is 1.4% on Cortex-A9\n(highbank). Taking an average of 30 runs of \"hackbench -l 1000\" yields:\n\nBefore: 6.2191\nAfter: 6.1348\n\nWill Deacon reported similar delta on v6 with 11MPCore.\n\nThe asm \"memory clobber\" are needed here to ensure the percpu offset\ngets reloaded. Testing by Will found that this would not happen in\n__schedule() which is a bit of a special case as preemption is disabled\nbut the execution can move cores.\n\nSigned-off-by: Rob Herring <rob.herring@calxeda.com>\nAcked-by: Will Deacon <will.deacon@arm.com>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","Rob Herring",true],["16bf00e77bf1d6feb77d06457906e511dab9f8ef","be5b96b982d71a0e8c9df1629ed76a94a416b6dd@codeaurora.org","msm: kgsl: Fix Z180 memory leak\n\nDecerement entry refcount, which incremented\nin kgsl_sharedmem_find_region.\n\nCRs-Fixed: 635747\nChange-Id: I621ba8f8e119a9ab8ba5455b28a565e3cae2f7cd\nSigned-off-by: Hareesh Gundu <hareeshg@codeaurora.org>","Hareesh Gundu",true],["45cf24bf7ad5c29d791b15c99c1f048e0813ad45","be5b96b982d71a0e8c9df1629ed76a94a416b6dd@codeaurora.org","msm: kgsl: Fix mem leak when page allocation fails\n\nPage allocation may fail during OOM condition. Update\nsglen and size to correct value (allocated) so that\nthey get freed in kgsl_sharedmem_free().\n\nChange-Id: I1aa0ca77bb767523dfcf0f6cc3a21eac2b6b80e4\nSigned-off-by: Hareesh Gundu <hareeshg@codeaurora.org>","Hareesh Gundu",true],["075182d1b222510cc592435680ed35e6f3b5603a","d77b46f71ad07d1c66a004715c9110750816d270@motorola.com","ARM: module: add text.unlikely section to unwind\n\nAdd handling for the .text.unlikely unwind sections for cases where\nreal used code get incorrectly placed by compiler. This solves cases\nin which a frequently used function triggers the collectoin of the\ncurrent stack trace when using CONFIG_ARM_UNWIND. An example would\nbe when using CONFIG_SLUB_DEBUG. The constant error printing can\nflood the kernel log buffers and cause sluggishness.\n\nChange-Id: I8ca99de24695a46e7fe461b5687c824b900908c8\nSigned-off-by: Jason Hrycay <jason.hrycay@motorola.com>\nReviewed-on: http://gerrit.pcs.mot.com/527901\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>\nReviewed-by: Check Patch <CHEKPACH@motorola.com>\nReviewed-by: Klocwork kwcheck <klocwork-kwcheck@sourceforge.mot.com>","Jason Hrycay",true],["bd7ac3a1275f9bbcd54e2cf81eec0388c0598815","1c3a980dc8904497e49ebc91fe67bb60e7f048ac@codeaurora.org","Perf: Add cortex A7 perf support\n\nSupport perf events for cortex-A7 PMU\n\nChange-Id: Ie44b077d56f9b538e99ae675efaf1829c1b752b7\nSigned-off-by: Neil Leeder <nleeder@codeaurora.org>","Neil Leeder",true],["b3937fba21491cb8595287c95cea5cbba0f4d27c","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","ARM: Disable unaligned instructions due to unexplanable unaligned exceptions\n\nThere's a bug where when unaligned access was enabled and with compiler\ngenerating unaligned instructions, unaligned exception was occurring.  This\nshouldn't happen but it did.  So disable for now until further analysis.\n\nChange-Id: I2f9b6f854d00c27d4755c3b9a66e6bfae2051ca4\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true],["60fd2c1d0aefb2de2340ad6b5375621986fbcc69","b913f13ef92ac157955c954ccaaff7be065faba4@arm.com","ARM: 7927/1: dcache: select DCACHE_WORD_ACCESS for big-endian CPUs\n\nWith commit 11ec50caedb5 (\"word-at-a-time: provide generic big-endian\nzero_bytemask implementation\"), the asm-generic word-at-a-time code now\nprovides a zero_bytemask implementation, allowing us to make use of\nDCACHE_WORD_ACCESS on big-endian CPUs, providing our\nload_unaligned_zeropad function is endianness-clean.\n\nThis patch reworks the load_unaligned_zeropad fixup code to work for\nboth big- and little-endian CPUs, then removes the !CPU_BIG_ENDIAN check\nwhen selecting DCACHE_WORD_ACCESS.\n\nSigned-off-by: Will Deacon <will.deacon@arm.com>\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>","Will Deacon",true],["14ad53d8bea27675f3eeb8f7cc9d47626657168b","356acbb50cdcf1cd2551e3930f6069c71a358592@nvidia.com","timekeeping: Fix time moving backwards\n\nChanged the calculation logic that sometimes calculates\nthe time wrong.\n\nSometimes there is an overflow when the tv_nsec field in\nthe timespec structure is being added since it is 32-bit.\n\nTo resolve this issue nsec variable is being added first\nso that the addition is performed in 64 bit signed format.\n\nBug 1217429\n\nChange-Id: I9c65da88f02596ba73c47be6342ed909e650db22\nSigned-off-by: Ajay Nandakumar <anandakumarm@nvidia.com>\nReviewed-on: http://git-master/r/195092\nReviewed-by: Automatic_Commit_Validation_User\nReviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>\nReviewed-by: Shridhar Rasal <srasal@nvidia.com>\nReviewed-by: Bo Yan <byan@nvidia.com>\nGVS: Gerrit_Virtual_Submit\nReviewed-by: Bharat Nihalani <bnihalani@nvidia.com>\nTested-by: Shridhar Rasal <srasal@nvidia.com>","Ajay Nandakumar",true],["25c83a79a138eee5bcadc4fb4e3e0edf4d5e0458","bf687672b62c2181dfefd4771873b9307f539e64@online.de","sched,rt: disable rt_runtime borrowing by default\n\nMake the default RT_RUNTIME_SHARE setting reflect the most common\nthrottle role, that of safety mechanism to protect the box.\n\nBug 1269903\n\nChange-Id: Id4ccf0095ea254f2e15fddc7ab02069f7f60a7c0\nSigned-off-by: Mike Galbraith <bitbucket@online.de>\nReviewed-on: http://git-master/r/234274\n(cherry picked from commit be74a12c8d8b987f569cdd0eec2aead3dcbdfa31)\nReviewed-on: http://git-master/r/237266\nTested-by: Peter Boonstoppel <pboonstoppel@nvidia.com>\nReviewed-by: Peter Boonstoppel <pboonstoppel@nvidia.com>\nReviewed-by: Automatic_Commit_Validation_User\nReviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>\nReviewed-by: Paul Walmsley <pwalmsley@nvidia.com>\nGVS: Gerrit_Virtual_Submit","Mike Galbraith",true],["20923512f9e021cf8ce8f035f212897f448b4f09","e5de08c96da1cc296eb9ce61b18b8780882255a2@gmail.com","SCHEDULER: Autogroup patch group by current user android UID instead of task ID","Lance Poore",true],["ff770baf7451bc0a72aa201532386666697debb9","a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","mutex: Make more scalable by doing less atomic operations\n\nDate\tMon, 15 Apr 2013 10:37:57 -0400\n\nIn the __mutex_lock_common() function, an initial entry into\nthe lock slow path will cause two atomic_xchg instructions to be\nissued. Together with the atomic decrement in the fast path, a total\nof three atomic read-modify-write instructions will be issued in\nrapid succession. This can cause a lot of cache bouncing when many\ntasks are trying to acquire the mutex at the same time.\n\nThis patch will reduce the number of atomic_xchg instructions used by\nchecking the counter value first before issuing the instruction. The\natomic_read() function is just a simple memory read. The atomic_xchg()\nfunction, on the other hand, can be up to 2 order of magnitude or even\nmore in cost when compared with atomic_read(). By using atomic_read()\nto check the value first before calling atomic_xchg(), we can avoid a\nlot of unnecessary cache coherency traffic. The only downside with this\nchange is that a task on the slow path will have a tiny bit\nless chance of getting the mutex when competing with another task\nin the fast path.\n\nThe same is true for the atomic_cmpxchg() function in the\nmutex-spin-on-owner loop. So an atomic_read() is also performed before\ncalling atomic_cmpxchg().\n\nThe mutex locking and unlocking code for the x86 architecture can allow\nany negative number to be used in the mutex count to indicate that some\ntasks are waiting for the mutex. I am not so sure if that is the case\nfor the other architectures. So the default is to avoid atomic_xchg()\nif the count has already been set to -1. For x86, the check is modified\nto include all negative numbers to cover a larger case.\n\nThe following table shows the jobs per minutes (JPM) scalability data\non an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl\ncommand is used to restrict the running of the high_systime workloads\nto 1/2/4/8 nodes with hyperthreading on and off.\n\n+-----------------+-----------+------------+----------+\n|  Configuration  | Mean JPM  |  Mean JPM  | % Change |\n|\t\t  | w/o patch | with patch |\t      |\n+-----------------+-----------------------------------+\n|\t\t  |      User Range 1100 - 2000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |    36980   |   148590  | +301.8%  |\n| 8 nodes, HT off |    42799   |   145011  | +238.8%  |\n| 4 nodes, HT on  |    61318   |   118445  |  +51.1%  |\n| 4 nodes, HT off |   158481   |   158592  |   +0.1%  |\n| 2 nodes, HT on  |   180602   |   173967  |   -3.7%  |\n| 2 nodes, HT off |   198409   |   198073  |   -0.2%  |\n| 1 node , HT on  |   149042   |   147671  |   -0.9%  |\n| 1 node , HT off |   126036   |   126533  |   +0.4%  |\n+-----------------+-----------------------------------+\n|\t\t  |       User Range 200 - 1000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |   41525    |   122349  | +194.6%  |\n| 8 nodes, HT off |   49866    |   124032  | +148.7%  |\n| 4 nodes, HT on  |   66409    |   106984  |  +61.1%  |\n| 4 nodes, HT off |  119880    |   130508  |   +8.9%  |\n| 2 nodes, HT on  |  138003    |   133948  |   -2.9%  |\n| 2 nodes, HT off |  132792    |   131997  |   -0.6%  |\n| 1 node , HT on  |  116593    |   115859  |   -0.6%  |\n| 1 node , HT off |  104499    |   104597  |   +0.1%  |\n+-----------------+------------+-----------+----------+\nAt low user range 10-100, the JPM differences were within +/-1%. So\nthey are not that interesting.\n\nAIM7 benchmark run has a pretty large run-to-run variance due to random\nnature of the subtests executed. So a difference of less than +-5%\nmay not be really significant.\n\nThis patch improves high_systime workload performance at 4 nodes\nand up by maintaining transaction rates without significant drop-off\nat high node count.  The patch has practically no impact on 1 and 2\nnodes system.\n\nThe table below shows the percentage time (as reported by perf\nrecord -a -s -g) spent on the __mutex_lock_slowpath() function by\nthe high_systime workload at 1500 users for 2/4/8-node configurations\nwith hyperthreading off.\n\n+---------------+-----------------+------------------+---------+\n| Configuration | %Time w/o patch | %Time with patch | %Change |\n+---------------+-----------------+------------------+---------+\n|    8 nodes    |      65.34%     |      0.69%       |  -99%   |\n|    4 nodes    |       8.70%\t  |      1.02%\t     |  -88%   |\n|    2 nodes    |       0.41%     |      0.32%       |  -22%   |\n+---------------+-----------------+------------------+---------+\nIt is obvious that the dramatic performance improvement at 8\nnodes was due to the drastic cut in the time spent within the\n__mutex_lock_slowpath() function.\n\nThe table below show the improvements in other AIM7 workloads (at 8\nnodes, hyperthreading off).\n\n+--------------+---------------+----------------+-----------------+\n|   Workload   | mean % change | mean % change  | mean % change   |\n|              | 10-100 users  | 200-1000 users | 1100-2000 users |\n+--------------+---------------+----------------+-----------------+\n| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |\n| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |\n| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |\n| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |\n| shared       |    +13.1%     |   +146.1%      |   +181.5%       |\n| short        |     +7.4%     |     +5.0%      |     +4.2%       |\n+--------------+---------------+----------------+-----------------+\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>","Waiman Long",true],["9642c0c54996ad1ef2ae95312a743ee12aacb71e","a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","mutex: back out architecture specific check for negative mutex count\n\nDate\tMon, 15 Apr 2013 10:37:59 -0400\n\nIf it is confirmed that all the supported architectures can allow a\nnegative mutex count without incorrect behavior, we can then back\nout the architecture specific change and allow the mutex count to\ngo to any negative number. That should further reduce contention for\nnon-x86 architecture.\n\nIf this is not the case, this patch should be dropped.\n\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>","Waiman Long",true],["78f73897e78a2794755924095356a42587731e93","a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","mutex: Make more scalable by doing less atomic operations\n\nDate\tMon, 15 Apr 2013 10:37:57 -0400\n\nIn the __mutex_lock_common() function, an initial entry into\nthe lock slow path will cause two atomic_xchg instructions to be\nissued. Together with the atomic decrement in the fast path, a total\nof three atomic read-modify-write instructions will be issued in\nrapid succession. This can cause a lot of cache bouncing when many\ntasks are trying to acquire the mutex at the same time.\n\nThis patch will reduce the number of atomic_xchg instructions used by\nchecking the counter value first before issuing the instruction. The\natomic_read() function is just a simple memory read. The atomic_xchg()\nfunction, on the other hand, can be up to 2 order of magnitude or even\nmore in cost when compared with atomic_read(). By using atomic_read()\nto check the value first before calling atomic_xchg(), we can avoid a\nlot of unnecessary cache coherency traffic. The only downside with this\nchange is that a task on the slow path will have a tiny bit\nless chance of getting the mutex when competing with another task\nin the fast path.\n\nThe same is true for the atomic_cmpxchg() function in the\nmutex-spin-on-owner loop. So an atomic_read() is also performed before\ncalling atomic_cmpxchg().\n\nThe mutex locking and unlocking code for the x86 architecture can allow\nany negative number to be used in the mutex count to indicate that some\ntasks are waiting for the mutex. I am not so sure if that is the case\nfor the other architectures. So the default is to avoid atomic_xchg()\nif the count has already been set to -1. For x86, the check is modified\nto include all negative numbers to cover a larger case.\n\nThe following table shows the jobs per minutes (JPM) scalability data\non an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl\ncommand is used to restrict the running of the high_systime workloads\nto 1/2/4/8 nodes with hyperthreading on and off.\n\n+-----------------+-----------+------------+----------+\n|  Configuration  | Mean JPM  |  Mean JPM  | % Change |\n|\t\t  | w/o patch | with patch |\t      |\n+-----------------+-----------------------------------+\n|\t\t  |      User Range 1100 - 2000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |    36980   |   148590  | +301.8%  |\n| 8 nodes, HT off |    42799   |   145011  | +238.8%  |\n| 4 nodes, HT on  |    61318   |   118445  |  +51.1%  |\n| 4 nodes, HT off |   158481   |   158592  |   +0.1%  |\n| 2 nodes, HT on  |   180602   |   173967  |   -3.7%  |\n| 2 nodes, HT off |   198409   |   198073  |   -0.2%  |\n| 1 node , HT on  |   149042   |   147671  |   -0.9%  |\n| 1 node , HT off |   126036   |   126533  |   +0.4%  |\n+-----------------+-----------------------------------+\n|\t\t  |       User Range 200 - 1000\t      |\n+-----------------+-----------------------------------+\n| 8 nodes, HT on  |   41525    |   122349  | +194.6%  |\n| 8 nodes, HT off |   49866    |   124032  | +148.7%  |\n| 4 nodes, HT on  |   66409    |   106984  |  +61.1%  |\n| 4 nodes, HT off |  119880    |   130508  |   +8.9%  |\n| 2 nodes, HT on  |  138003    |   133948  |   -2.9%  |\n| 2 nodes, HT off |  132792    |   131997  |   -0.6%  |\n| 1 node , HT on  |  116593    |   115859  |   -0.6%  |\n| 1 node , HT off |  104499    |   104597  |   +0.1%  |\n+-----------------+------------+-----------+----------+\nAt low user range 10-100, the JPM differences were within +/-1%. So\nthey are not that interesting.\n\nAIM7 benchmark run has a pretty large run-to-run variance due to random\nnature of the subtests executed. So a difference of less than +-5%\nmay not be really significant.\n\nThis patch improves high_systime workload performance at 4 nodes\nand up by maintaining transaction rates without significant drop-off\nat high node count.  The patch has practically no impact on 1 and 2\nnodes system.\n\nThe table below shows the percentage time (as reported by perf\nrecord -a -s -g) spent on the __mutex_lock_slowpath() function by\nthe high_systime workload at 1500 users for 2/4/8-node configurations\nwith hyperthreading off.\n\n+---------------+-----------------+------------------+---------+\n| Configuration | %Time w/o patch | %Time with patch | %Change |\n+---------------+-----------------+------------------+---------+\n|    8 nodes    |      65.34%     |      0.69%       |  -99%   |\n|    4 nodes    |       8.70%\t  |      1.02%\t     |  -88%   |\n|    2 nodes    |       0.41%     |      0.32%       |  -22%   |\n+---------------+-----------------+------------------+---------+\nIt is obvious that the dramatic performance improvement at 8\nnodes was due to the drastic cut in the time spent within the\n__mutex_lock_slowpath() function.\n\nThe table below show the improvements in other AIM7 workloads (at 8\nnodes, hyperthreading off).\n\n+--------------+---------------+----------------+-----------------+\n|   Workload   | mean % change | mean % change  | mean % change   |\n|              | 10-100 users  | 200-1000 users | 1100-2000 users |\n+--------------+---------------+----------------+-----------------+\n| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |\n| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |\n| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |\n| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |\n| shared       |    +13.1%     |   +146.1%      |   +181.5%       |\n| short        |     +7.4%     |     +5.0%      |     +4.2%       |\n+--------------+---------------+----------------+-----------------+\nSigned-off-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>\n\nChange-Id: Ib61194ccd6c8533ce4c88f4aa4a5a32236aebe20","Waiman Long",true],["6e5446924a0a4ebd2b517dc3187bd629d9bb1feb","d7ca2ed3e31360a26e5e60317ed1b792bd41becb@hp.com","lib/int_sqrt.c: optimize square root algorithm\n\nOptimize the current version of the shift-and-subtract (hardware)\nalgorithm, described by John von Newmann[1] and Guy L Steele.\n\nIterating 1,000,000 times, perf shows for the current version:\n\n Performance counter stats for './sqrt-curr' (10 runs):\n\n         27.170996 task-clock                #    0.979 CPUs utilized            ( +-  3.19% )\n                 3 context-switches          #    0.103 K/sec                    ( +-  4.76% )\n                 0 cpu-migrations            #    0.004 K/sec                    ( +-100.00% )\n               104 page-faults               #    0.004 M/sec                    ( +-  0.16% )\n        64,921,199 cycles                    #    2.389 GHz                      ( +-  0.03% )\n        28,967,789 stalled-cycles-frontend   #   44.62% frontend cycles idle     ( +-  0.18% )\n   <not supported> stalled-cycles-backend\n       104,502,623 instructions              #    1.61  insns per cycle\n                                             #    0.28  stalled cycles per insn  ( +-  0.00% )\n        34,088,368 branches                  # 1254.587 M/sec                    ( +-  0.00% )\n             4,901 branch-misses             #    0.01% of all branches          ( +-  1.32% )\n\n       0.027763015 seconds time elapsed                                          ( +-  3.22% )\n\nAnd for the new version:\n\nPerformance counter stats for './sqrt-new' (10 runs):\n\n          0.496869 task-clock                #    0.519 CPUs utilized            ( +-  2.38% )\n                 0 context-switches          #    0.000 K/sec\n                 0 cpu-migrations            #    0.403 K/sec                    ( +-100.00% )\n               104 page-faults               #    0.209 M/sec                    ( +-  0.15% )\n           590,760 cycles                    #    1.189 GHz                      ( +-  2.35% )\n           395,053 stalled-cycles-frontend   #   66.87% frontend cycles idle     ( +-  3.67% )\n   <not supported> stalled-cycles-backend\n           398,963 instructions              #    0.68  insns per cycle\n                                             #    0.99  stalled cycles per insn  ( +-  0.39% )\n            70,228 branches                  #  141.341 M/sec                    ( +-  0.36% )\n             3,364 branch-misses             #    4.79% of all branches          ( +-  5.45% )\n\n       0.000957440 seconds time elapsed                                          ( +-  2.42% )\n\nFurthermore, this saves space in instruction text:\n\n   text    data     bss     dec     hex filename\n    111       0       0     111      6f lib/int_sqrt-baseline.o\n     89       0       0      89      59 lib/int_sqrt.o\n\n[1] http://en.wikipedia.org/wiki/First_Draft_of_a_Report_on_the_EDVAC\n\nSigned-off-by: Davidlohr Bueso <davidlohr.bueso@hp.com>\nReviewed-by: Jonathan Gonzalez <jgonzlez@linets.cl>\nTested-by: Jonathan Gonzalez <jgonzlez@linets.cl>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Davidlohr Bueso",true],["feda85dff0774841e6106b69eab81fd4b66dc8c9","6affa2782fb8514898f88c7c4a087191fcbabb20@linux.vnet.ibm.com","sched: Implement smarter wake-affine logic\n\nThe wake-affine scheduler feature is currently always trying to pull\nthe wakee close to the waker. In theory this should be beneficial if\nthe waker's CPU caches hot data for the wakee, and it's also beneficial\nin the extreme ping-pong high context switch rate case.\n\nTesting shows it can benefit hackbench up to 15%.\n\nHowever, the feature is somewhat blind, from which some workloads\nsuch as pgbench suffer. It's also time-consuming algorithmically.\n\nTesting shows it can damage pgbench up to 50% - far more than the\nbenefit it brings in the best case.\n\nSo wake-affine should be smarter and it should realize when to\nstop its thankless effort at trying to find a suitable CPU to wake on.\n\nThis patch introduces 'wakee_flips', which will be increased each\ntime the task flips (switches) its wakee target.\n\nSo a high 'wakee_flips' value means the task has more than one\nwakee, and the bigger the number, the higher the wakeup frequency.\n\nNow when making the decision on whether to pull or not, pay attention to\nthe wakee with a high 'wakee_flips', pulling such a task may benefit\nthe wakee. Also imply that the waker will face cruel competition later,\nit could be very cruel or very fast depends on the story behind\n'wakee_flips', waker therefore suffers.\n\nFurthermore, if waker also has a high 'wakee_flips', that implies that\nmultiple tasks rely on it, then waker's higher latency will damage all\nof them, so pulling wakee seems to be a bad deal.\n\nThus, when 'waker->wakee_flips / wakee->wakee_flips' becomes\nhigher and higher, the cost of pulling seems to be worse and worse.\n\nThe patch therefore helps the wake-affine feature to stop its pulling\nwork when:\n\n\twakee->wakee_flips > factor &&\n\twaker->wakee_flips > (factor * wakee->wakee_flips)\nThe 'factor' here is the number of CPUs in the current CPU's NUMA node,\nso a bigger node will lead to more pulling since the trial becomes more\nsevere.\n\nAfter applying the patch, pgbench shows up to 40% improvements and no regressions.\n\nTested with 12 cpu x86 server and tip 3.10.0-rc7.\n\nThe percentages in the final column highlight the areas with the biggest wins,\nall other areas improved as well:\n\n\tpgbench\t\t    base\tsmart\n\n\t| db_size | clients |  tps  |\t|  tps  |\n\t+---------+---------+-------+   +-------+\n\t| 22 MB   |       1 | 10598 |   | 10796 |\n\t| 22 MB   |       2 | 21257 |   | 21336 |\n\t| 22 MB   |       4 | 41386 |   | 41622 |\n\t| 22 MB   |       8 | 51253 |   | 57932 |\n\t| 22 MB   |      12 | 48570 |   | 54000 |\n\t| 22 MB   |      16 | 46748 |   | 55982 | +19.75%\n\t| 22 MB   |      24 | 44346 |   | 55847 | +25.93%\n\t| 22 MB   |      32 | 43460 |   | 54614 | +25.66%\n\t| 7484 MB |       1 |  8951 |   |  9193 |\n\t| 7484 MB |       2 | 19233 |   | 19240 |\n\t| 7484 MB |       4 | 37239 |   | 37302 |\n\t| 7484 MB |       8 | 46087 |   | 50018 |\n\t| 7484 MB |      12 | 42054 |   | 48763 |\n\t| 7484 MB |      16 | 40765 |   | 51633 | +26.66%\n\t| 7484 MB |      24 | 37651 |   | 52377 | +39.11%\n\t| 7484 MB |      32 | 37056 |   | 51108 | +37.92%\n\t| 15 GB   |       1 |  8845 |   |  9104 |\n\t| 15 GB   |       2 | 19094 |   | 19162 |\n\t| 15 GB   |       4 | 36979 |   | 36983 |\n\t| 15 GB   |       8 | 46087 |   | 49977 |\n\t| 15 GB   |      12 | 41901 |   | 48591 |\n\t| 15 GB   |      16 | 40147 |   | 50651 | +26.16%\n\t| 15 GB   |      24 | 37250 |   | 52365 | +40.58%\n\t| 15 GB   |      32 | 36470 |   | 50015 | +37.14%\nSigned-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/51D50057.9000809@linux.vnet.ibm.com\n[ Improved the changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Michael Wang",true],["aaa668d89a6a650a0876e57f5346c95136df8325","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","sched: Micro-optimize the smart wake-affine logic\n\nSmart wake-affine is using node-size as the factor currently, but the overhead\nof the mask operation is high.\n\nThus, this patch introduce the 'sd_llc_size' percpu variable, which will record\nthe highest cache-share domain size, and make it to be the new factor, in order\nto reduce the overhead and make it more reasonable.\n\nTested-by: Davidlohr Bueso <davidlohr.bueso@hp.com>\nTested-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nAcked-by: Michael Wang <wangyun@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nLink: http://lkml.kernel.org/r/51D5008E.6030102@linux.vnet.ibm.com\n[ Tidied up the changelog. ]\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n\nChange-Id: If568811cf199e27ae36f6c62efb49b8b23a97e8d","Peter Zijlstra",true],["000740437e0ab6f1938c45b430a372dd4d69a079","0d62248ee021b6e01c0ee596a62a5b145b996974@parallels.com","sched: add wait_for_completion_io[_timeout]\n\nThe only difference between wait_for_completion[_timeout]() and\nwait_for_completion_io[_timeout]() is that the latter calls\nio_schedule_timeout() instead of schedule_timeout() so that the caller\nis accounted as waiting for IO, not just sleeping.\n\nThese functions can be used for correct iowait time accounting when the\ncompletion struct is actually used for waiting for IO (e.g. completion\nof a bio request in the block layer).\n\nModified to compile with 3.4.0 on the Nexus 4 (Mako)\n\nSigned-off-by: Vladimir Davydov <vdavydov@parallels.com>\nAcked-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Vladimir Davydov",true]],"size":22,"ref":"refs/heads/android-4.4-next","head":"35c0b23f98e0564ec86abeb3a2c79174eb611a35"}