GitHub PushEvent at 2014-03-21 22:00:42
Repository: android_kernel_motorola_msm8226
Actor: pinkflozd
Payload: {"shas":[["d625cbe95fcd3d56eeceefb1e8dec89588c2b346","5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","sched: Optimize build_sched_domains() for saving first SD node for a cpu\n\nWe are saving first scheduling domain for a cpu in build_sched_domains() by\niterating over the nested sd->child list. We don't actually need to do it this\nway.\n\ntl will be equal to sched_domain_topology for the first iteration and so we can\nset *per_cpu_ptr(d.sd, i) based on that.  So, save pointer to first SD while\nrunning the iteration loop over tl's.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Viresh Kumar",true],["a1a1fd3a248188d5b20d6a1ddb44436c7d1df725","5ff32272b3d9f86512eddc8e0af523fc6f7924e5@linaro.org","sched: Remove unused params of build_sched_domain()\n\nDate\tTue, 4 Jun 2013 16:50:19 +0530\n\nbuild_sched_domain() never uses parameter struct s_data *d and so passing it is\nuseless.\n\nRemove it.\n\nSigned-off-by: Viresh Kumar <viresh.kumar@linaro.org>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Viresh Kumar",true],["e5407dd1821995842deadf9fc71d9d8e53ae6bc7","4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","futex: Misc cleanups\n\nDate\tThu, 2 Jan 2014 07:05:17 -0800\n\nFrom: Jason Low <jason.low2@hp.com>\n\n- Remove unnecessary head variables.\n- Delete unused parameter in queue_unlock().\n\nCc: Ingo Molnar <mingo@kernel.org>\nReviewed-by: Darren Hart <dvhart@linux.intel.com>\nAcked-by: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nCc: Waiman Long <Waiman.Long@hp.com>\nSigned-off-by: Jason Low <jason.low2@hp.com>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Davidlohr Bueso",true],["8c52499f298ff02c80a95b6ba188c094e0750dfa","4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","futex: Larger hash table\n\nDate\tThu, 2 Jan 2014 07:05:18 -0800\n\nFrom: Davidlohr Bueso <davidlohr@hp.com>\n\nCurrently, the futex global hash table suffers from it's fixed, smallish\n(for today's standards) size of 256 entries, as well as its lack of NUMA\nawareness. Large systems, using many futexes, can be prone to high amounts\nof collisions; where these futexes hash to the same bucket and lead to\nextra contention on the same hb->lock. Furthermore, cacheline bouncing is a\nreality when we have multiple hb->locks residing on the same cacheline and\ndifferent futexes hash to adjacent buckets.\nThis patch keeps the current static size of 16 entries for small systems,\nor otherwise, 256 * ncpus (or larger as we need to round the number to a\npower of 2). Note that this number of CPUs accounts for all CPUs that can\never be available in the system, taking into consideration things like\nhotpluging. While we do impose extra overhead at bootup by making the hash\ntable larger, this is a one time thing, and does not shadow the benefits\nof this patch.\n\nFurthermore, as suggested by tglx, by cache aligning the hash buckets we can\navoid access across cacheline boundaries and also avoid massive cache line\nbouncing if multiple cpus are hammering away at different hash buckets which\nhappen to reside in the same cache line.\n\nAlso, similar to other core kernel components (pid, dcache, tcp), by using\nalloc_large_system_hash() we benefit from its NUMA awareness and thus the\ntable is distributed among the nodes instead of in a single one.\n\nFor a custom microbenchmark that pounds on the uaddr hashing -- making the wait\npath fail at futex_wait_setup() returning -EWOULDBLOCK for large amounts of\nfutexes, we can see the following benefits on a 80-core, 8-socket 1Tb server:\n\n+---------+--------------------+------------------------+-----------------------+-------------------------------+\n| threads | baseline (ops/sec) | aligned-only (ops/sec) | large table (ops/sec) | large table+aligned (ops/sec) |\n+---------+--------------------+------------------------+-----------------------+-------------------------------+\n|     512 |\t\t 32426 | 50531  (+55.8%)\t| 255274  (+687.2%)\t| 292553  (+802.2%)\t\t|\n|     256 |\t\t 65360 | 99588  (+52.3%)\t| 443563  (+578.6%)\t| 508088  (+677.3%)\t\t|\n|     128 |\t\t125635 | 200075 (+59.2%)\t| 742613  (+491.1%)\t| 835452  (+564.9%)\t\t|\n|      80 |\t\t193559 | 323425 (+67.1%)\t| 1028147 (+431.1%)\t| 1130304 (+483.9%)\t\t|\n|      64 |\t\t247667 | 443740 (+79.1%)\t| 997300  (+302.6%)\t| 1145494 (+362.5%)\t\t|\n|      32 |\t\t628412 | 721401 (+14.7%)\t| 965996  (+53.7%)\t| 1122115 (+78.5%)\t\t|\n+---------+--------------------+------------------------+-----------------------+-------------------------------+\nCc: Ingo Molnar <mingo@kernel.org>\nReviewed-by: Darren Hart <dvhart@linux.intel.com>\nAcked-by: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nReviewed-by: Waiman Long <Waiman.Long@hp.com>\nReviewed-and-tested-by: Jason Low <jason.low2@hp.com>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Davidlohr Bueso",true],["d46898bc2c23628219172709e3ab00db4b8c0f75","4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","futex: Document ordering guarantees\n\nDate\tThu, 2 Jan 2014 07:05:19 -0800\n\nFrom: Thomas Gleixner <tglx@linutronix.de>\n\nThat's essential, if you want to hack on futexes.\n\nCc: Ingo Molnar <mingo@kernel.org>\nCc: Darren Hart <dvhart@linux.intel.com>\nAcked-by: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Randy Dunlap <rdunlap@infradead.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nCc: Waiman Long <Waiman.Long@hp.com>\nCc: Jason Low <jason.low2@hp.com>\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Davidlohr Bueso",true],["84ec3210de05ae4af67008330b762ff366ebf54f","4aa5652442886f3c4e77d3a743dc27e129c1613f@hp.com","futex: Avoid taking hb lock if nothing to wakeup\n\nDate\tThu, 2 Jan 2014 07:05:20 -0800\n\nFrom: Davidlohr Bueso <davidlohr@hp.com>\n\nIn futex_wake() there is clearly no point in taking the hb->lock if we know\nbeforehand that there are no tasks to be woken. While the hash bucket's plist\nhead is a cheap way of knowing this, we cannot rely 100% on it as there is a\nracy window between the futex_wait call and when the task is actually added to\nthe plist. To this end, we couple it with the spinlock check as tasks trying to\nenter the critical region are most likely potential waiters that will be added\nto the plist, thus preventing tasks sleeping forever if wakers don't acknowledge\nall possible waiters.\n\nFurthermore, the futex ordering guarantees are preserved, ensuring that waiters\neither observe the changed user space value before blocking or is woken by a\nconcurrent waker. For wakers, this is done by relying on the barriers in\nget_futex_key_refs() -- for archs that do have implicit mb in atomic_inc() we\nexplicitly add them through a new futex_get_mm function. For waiters we rely\non the fact that spin_lock calls already update the head counter, so spinners\nare visible even if the lock hasn't been acquired yet.\n\nFor more details please refer to the updated comments in the code and related\ndiscussion: https://lkml.org/lkml/2013/11/26/556\n\nSpecial thanks to tglx for careful review and feedback.\n\nCc: Ingo Molnar <mingo@kernel.org>\nCc: Darren Hart <dvhart@linux.intel.com>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nCc: Mike Galbraith <efault@gmx.de>\nCc: Jeff Mahoney <jeffm@suse.com>\nSuggested-by: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Scott Norton <scott.norton@hp.com>\nCc: Tom Vaden <tom.vaden@hp.com>\nCc: Aswin Chandramouleeswaran <aswin@hp.com>\nCc: Waiman Long <Waiman.Long@hp.com>\nCc: Jason Low <jason.low2@hp.com>\nSigned-off-by: Davidlohr Bueso <davidlohr@hp.com>\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Davidlohr Bueso",true],["eb5db244cec2d0a14ec96ba39a640c43ac9c8f2a","c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","kernel/futex.c: Linux 3.4 compatibility fix up\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>","Paul Reioux",true]],"size":7,"ref":"refs/heads/kk-new","head":"eb5db244cec2d0a14ec96ba39a640c43ac9c8f2a"}