GitHub PushEvent at 2014-04-25 13:53:25
Repository: android_kernel_motorola_omap4-common
Actor: nx111
Payload: {"shas":[["c920a171fdda0d6ac3a9ed2e018b98deb863865b","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","JBX-Kernel 3.2","dtrail",true],["8edfdfed9d72ac0ff0ffc244142c28f0d6f06958","eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","ARM: cpu topology: Add asym topology flag for using cpu0 1st\n\nModify the CPU sched_domain flags in powersave mode for using the cpu0 in ched_mc powersave mode\n\nSigned-off-by: Vincent Guittot <vincent.guittot@linaro.org>\nSigned-off-by: nicholas <firepoison35@gmail.com>\n\nConflicts:\n\tarch/arm/include/asm/topology.h\n\nConflicts:\n\tarch/arm/include/asm/topology.h\n\nChange-Id: Ibac5293abadd98130b888032eff26d1dffeb3a9c","Vincent Guittot",true],["13f26683e63e13f762fb6303ac5f4b8a8eccf2a6","eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","ARM: topology: save cpu id of each core","Vincent Guittot",true],["9d3054505766e3901be6c1b7324fbf78b2d93b05","6eeda38f716f799d41c9ff362f332d2a129ac339@gmail.com","ARM: topology: Add a topology update notification\n\nChange-Id: Ib50f3d128b3d927aac3ffe74850fb6d9dcf5c484","nx111",true],["beb489b6d027b70a5ef6889d1ca5ec87478f97d4","eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","ARM: cpu topology: Add asym topology flag for using cpu0 1st","Vincent Guittot",true],["874beb5edbccc6e9a25606d50a3626f774870a94","8de95bd08b913dc7fccd660e4e165035a8117ef9@gmail.com","block: Add Zen I/O scheduler. Similar to SIO, primarily based on noop and deadline. Intended to be mostly FCFS. Simpler than SIO in many ways, one of them being write requests/read requests have mostly the same priority.","ktoonsez",true],["d86b75ac0fdbb1801a412cf16d903f40413a1c93","42480b5f4d505650064e5081b85d867a03559887@gmail.com","arm: mutex: merge Will Deacon's patch for including a different implementationfor mutexes for ARM6+ chips. Didn't cherry pick original patches because they conflicted for some reason and I felt too lazy to fix the conflict.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\nSigned-off-by: nicholas <firepoison35@gmail.com>\n\nConflicts:\n\tarch/arm/include/asm/mutex.h","Francisco Franco",true],["406dcdb5f80f0f8f2d3fa21381576f4550f2ef5e","a123fdd9fb50e93f03393cfddab9c182b4164439@hp.com","mutex: Make more scalable by doing less atomic operations\n\nDate\tThu, 4 Apr 2013 10:54:16 -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 scalability data on an 8-node 80-core\nWestmere box with a 3.7.10 kernel. The numactl command is used to\nrestrict the running of the high_systime workloads to 1/2/4/8 nodes\nwith hyperthreading on and off.\n\n+-----------------+------------------+------------------+----------+\n|  Configuration  | Mean Transaction | Mean Transaction | % Change |\n|\t\t  |  Rate w/o patch  | Rate with patch  |\t   |\n+-----------------+------------------------------------------------+\n|\t\t  |              User Range 1100 - 2000\t\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  |\t 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\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  |\t 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+-----------------+------------------+------------------+----------+\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\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","Waiman Long",true],["6ca48069ba9687acc7decf1e0690057f6b23bc50","b87ef1d067dec8e3128483304870e80cbbb77bd5@gmail.com"," block: blk-merge: don't merge the pages with non-contiguous descriptors\n\nblk_rq_map_sg() function merges the physically contiguous pages to use same\nscatter-gather node without checking if their page descriptors are\ncontiguous or not.\n\nNow when dma_map_sg() is called on the scatter gather list, it would\ntake the base page pointer from each node (one by one) and iterates\nthrough all of the pages in same sg node by keep incrementing the base\npage pointer with the assumption that physically contiguous pages will\nhave their page descriptor address contiguous which may not be true\nif SPARSEMEM config is enabled. So here we may end referring to invalid\npage descriptor.\n\nFollowing table shows the example of physically contiguous pages but\ntheir page descriptor addresses non-contiguous.\n-------------------------------------------\n| Page Descriptor    |   Physical Address |\n------------------------------------------\n| 0xc1e43fdc         |   0xdffff000       |\n| 0xc2052000         |   0xe0000000       |\n-------------------------------------------\n\nWith this patch, relevant blk-merge functions will also check if the\nphysically contiguous pages are having page descriptors address contiguous\nor not? If not then, these pages are separated to be in different\nscatter-gather nodes.\n\nSigned-off-by: Subhash Jadavani <subhashj@codeaurora.org>\nSigned-off-by: nicholas <firepoison35@gmail.com>","nicholas",true],["da35a8a036f4e46cf1009c045f7701fb6eef0df5","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","block: enable IO changes","dtrail",true],["e1b7215fac6f04faf84bfdba6ca59b93a21a6509","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","perf_event: just a little typo","dtrail",true],["644e7a7f86743a2c204e177bd38e7db736260cb1","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","small bt changes","dtrail",true],["ab90abd5e126cd42286b82cb3fbad02623dc25c2","a15f8b81a160b4eebe5c84e9e3b65c87b9b2f18e@cerrato.biz","cpufreq: make rw = 0664\n\nChange-Id: I4a676278adb6ffa620e89d4fc9e8fb0266c986d7","Ivan Cerrato",true],["6fdae8903057d461f962e741dea32a4e767be940","a15f8b81a160b4eebe5c84e9e3b65c87b9b2f18e@cerrato.biz","sdhci: workaround from lkml\n\nChange-Id: I103a2f1a555a22e425636355651a760a1704c87f","Ivan Cerrato",true],["513d333b90c50cb028e8dfb7a9c19c299760336d","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","staging: binder: backport from 3.1","dtrail",true],["b1e56e76c1815fb511062ce314f8b3d2b7247d1c","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","Revert \"sdhci: workaround from lkml\"\n\nThis reverts commit 33f340437f0eba23003b423cbcab9e5bade7d795.","dtrail",true],["1603a626476e655920815dae42d46d734be2b920","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","Revert \"Revert \"sdhci: workaround from lkml\"\"\n\nThis reverts commit e3202292deac8f6061e4187622c5fadd7bdbba8f.","dtrail",true],["685675c8cfa1bb6053d6387a4f84011fe9956b27","eb7d4bc75c19026be4afbcab4b7b388cf01677ff@linaro.org","topology: update to latest upstream version","Vincent Guittot",true]],"size":18,"ref":"refs/heads/JBX_30X","head":"685675c8cfa1bb6053d6387a4f84011fe9956b27"}