{"push_id":2606777497,"size":1,"distinct_size":0,"ref":"refs/heads/caf/aosp-common/android-4.4","head":"54f36eadd123b33d8bad8c6784d0450a00d34a45","before":"3f51ea2db97d9b434b4f4faca31c82a41c5c3722","commits":[{"sha":"54f36eadd123b33d8bad8c6784d0450a00d34a45","author":{"name":"Joel Fernandes","email":"89f39a38232ac523c7644e47b6ca6563177e40b4@google.com"},"message":"UPSTREAM: sched/fair: Consider RT/IRQ pressure in capacity_spare_wake\n\ncapacity_spare_wake in the slow path influences choice of idlest groups,\nas we search for groups with maximum spare capacity. In scenarios where\nRT pressure is high, a sub optimal group can be chosen and hurt\nperformance of the task being woken up.\n\nSeveral tests with results are included below to show improvements with\nthis change.\n\n1) Hackbench on Pixel 2 Android device (4x4 ARM64 Octa core)\n------------------------------------------------------------\nHere we have RT activity running on big CPU cluster induced with rt-app,\nand running hackbench in parallel. The RT tasks are bound to 4 CPUs on\nthe big cluster (cpu 4,5,6,7) and have 100ms periodicity with\nruntime=20ms sleep=80ms.\n\nHackbench shows big benefit (30%) improvement when number of tasks is 8\nand 32: Note: data is completion time in seconds (lower is better).\nNumber of loops for 8 and 16 tasks is 50000, and for 32 tasks its 20000.\n+--------+-----+-------+-------------------+---------------------------+\n| groups | fds | tasks | Without Patch     | With Patch                |\n+--------+-----+-------+---------+---------+-----------------+---------+\n|        |     |       | Mean    | Stdev   | Mean            | Stdev   |\n|        |     |       +-------------------+-----------------+---------+\n|      1 |   8 |     8 | 1.0534  | 0.13722 | 0.7293 (+30.7%) | 0.02653 |\n|      2 |   8 |    16 | 1.6219  | 0.16631 | 1.6391 (-1%)    | 0.24001 |\n|      4 |   8 |    32 | 1.2538  | 0.13086 | 1.1080 (+11.6%) | 0.16201 |\n+--------+-----+-------+---------+---------+-----------------+---------+\n\n2) Rohit ran barrier.c test (details below) with following improvements:\n------------------------------------------------------------------------\nThis was Rohit's original use case for a patch he posted at [1] however\nfrom his recent tests he showed my patch can replace his slow path\nchanges [1] and there's no need to selectively scan/skip CPUs in\nfind_idlest_group_cpu in the slow path to get the improvement he sees.\n\nbarrier.c (open_mp code) as a micro-benchmark. It does a number of\niterations and barrier sync at the end of each for loop.\n\nHere barrier,c is running in along with ping on CPU 0 and 1 as:\n'ping -l 10000 -q -s 10 -f hostX'\n\nbarrier.c can be found at:\nhttp://www.spinics.net/lists/kernel/msg2506955.html\n\nFollowing are the results for the iterations per second with this\nmicro-benchmark (higher is better), on a 44 core, 2 socket 88 Threads\nIntel x86 machine:\n+--------+------------------+---------------------------+\n|Threads | Without patch    | With patch                |\n|        |                  |                           |\n+--------+--------+---------+-----------------+---------+\n|        | Mean   | Std Dev | Mean            | Std Dev |\n+--------+--------+---------+-----------------+---------+\n|1       | 539.36 | 60.16   | 572.54 (+6.15%) | 40.95   |\n|2       | 481.01 | 19.32   | 530.64 (+10.32%)| 56.16   |\n|4       | 474.78 | 22.28   | 479.46 (+0.99%) | 18.89   |\n|8       | 450.06 | 24.91   | 447.82 (-0.50%) | 12.36   |\n|16      | 436.99 | 22.57   | 441.88 (+1.12%) | 7.39    |\n|32      | 388.28 | 55.59   | 429.4  (+10.59%)| 31.14   |\n|64      | 314.62 | 6.33    | 311.81 (-0.89%) | 11.99   |\n+--------+--------+---------+-----------------+---------+\n\n3) ping+hackbench test on bare-metal sever (Rohit ran this test)\n----------------------------------------------------------------\nHere hackbench is running in threaded mode along\nwith, running ping on CPU 0 and 1 as:\n'ping -l 10000 -q -s 10 -f hostX'\n\nThis test is running on 2 socket, 20 core and 40 threads Intel x86\nmachine:\nNumber of loops is 10000 and runtime is in seconds (Lower is better).\n\n+--------------+-----------------+--------------------------+\n|Task Groups   | Without patch   |  With patch              |\n|              +-------+---------+----------------+---------+\n|(Groups of 40)| Mean  | Std Dev |  Mean          | Std Dev |\n+--------------+-------+---------+----------------+---------+\n|1             | 0.851 | 0.007   |  0.828 (+2.77%)| 0.032   |\n|2             | 1.083 | 0.203   |  1.087 (-0.37%)| 0.246   |\n|4             | 1.601 | 0.051   |  1.611 (-0.62%)| 0.055   |\n|8             | 2.837 | 0.060   |  2.827 (+0.35%)| 0.031   |\n|16            | 5.139 | 0.133   |  5.107 (+0.63%)| 0.085   |\n|25            | 7.569 | 0.142   |  7.503 (+0.88%)| 0.143   |\n+--------------+-------+---------+----------------+---------+\n\n[1] https://patchwork.kernel.org/patch/9991635/\n\nMatt Fleming also ran cyclictest and several different hackbench tests\non his test machines to santiy-check that the patch doesn't harm any\nof his usecases.\n\nChange-Id: Ibcedbb65273545ff2f4d1962b4eaca14072b1bd2\nCc: Dietmar Eggemann <dietmar.eggemann@arm.com>\nCc: Vincent Guittot <vincent.guittot@linaro.org>\nCc: Morten Ramussen <morten.rasmussen@arm.com>\nCc: Brendan Jackman <brendan.jackman@arm.com>\nTested-by: Rohit Jain <rohit.k.jain@oracle.com>\nTested-by: Matt Fleming <matt@codeblueprint.co.uk>\nSigned-off-by: Joel Fernandes <joelaf@google.com>\nReviewed-by: Vincent Guittot <vincent.guittot@linaro.org>\nReviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>","distinct":false,"url":"https://api.github.com/repos/akhilnarang/kernel_msm-3.10/commits/54f36eadd123b33d8bad8c6784d0450a00d34a45"}]}
{"actor":{"display_login":"akhilnarang"}}