{"push_id":609344129,"size":31,"distinct_size":31,"ref":"refs/heads/master","head":"3b7438c7bec03893fca3feec3a240a83e25c5f2c","before":"3008d17adc6b9fbcad931217d40804205c365769","commits":[{"sha":"eb9c1cf9ddf1d4dde187fd4f82e424faac9fb29a","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" timer: Fix mod_timer_pinned() header comment\n\nThe mod_timer_pinned() header comment states that it prevents timers\nfrom being migrated to a different CPU.  This is not the case, instead,\nit ensures that the timer is posted to the current CPU, but does nothing\nto prevent CPU-hotplug operations from migrating the timer.\n\nThis commit therefore brings the comment header into alignment with\nreality.\n\nSigned-off-by: Paul E. McKenney <paul.mckenney@linaro.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nAcked-by: Steven Rostedt <rostedt@goodmis.org>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/eb9c1cf9ddf1d4dde187fd4f82e424faac9fb29a"},{"sha":"19fbc462737e4facf6313b1790947fa7dfa0730f","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" rcu: Update RCU_FAST_NO_HZ tracing for lazy callbacks\n\nIn the current code, a short dyntick-idle interval (where there is\nat least one non-lazy callback on the CPU) and a long dyntick-idle\ninterval (where there are only lazy callbacks on the CPU) are traced\nidentically, which can be less than helpful.  This commit therefore\nemits different event traces in these two cases.\n\nSigned-off-by: Paul E. McKenney <paul.mckenney@linaro.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nTested-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nTested-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/19fbc462737e4facf6313b1790947fa7dfa0730f"},{"sha":"a53e2ff531963df49fcd0c1a2760d6e521e2fffc","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" rcu: Move RCU_FAST_NO_HZ per-CPU variables to rcu_dynticks structure\n\nThe RCU_FAST_NO_HZ code relies on a number of per-CPU variables.\nThis works, but is hidden from someone scanning the data structures\nin rcutree.h.  This commit therefore converts these per-CPU variables\nto fields in the per-CPU rcu_dynticks structures.\n\nSuggested-by: Peter Zijlstra <peterz@infradead.org>\nSigned-off-by: Paul E. McKenney <paul.mckenney@linaro.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nTested-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nTested-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/a53e2ff531963df49fcd0c1a2760d6e521e2fffc"},{"sha":"22fe38fdca8c9a6eedef3dec4b33d63ee047dae6","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" rcu: Precompute RCU_FAST_NO_HZ timer offsets\n\nWhen a CPU is entering dyntick-idle mode, tick_nohz_stop_sched_tick()\ncalls rcu_needs_cpu() see if RCU needs that CPU, and, if not, computes the\nnext wakeup time based on the timer wheels.  Only later, when actually\nentering the idle loop, rcu_prepare_for_idle() will be invoked.  In some\ncases, rcu_prepare_for_idle() will post timers to wake the CPU back up.\nBut all for naught: The next wakeup time for the CPU has already been\ncomputed, and posting a timer afterwards does not force that wakeup\ntime to be recomputed.  This means that rcu_prepare_for_idle()'s have\nno effect.\n\nThis is not a problem on a busy system because something else will wake\nup the CPU soon enough.  However, on lightly loaded systems, the CPU\nmight stay asleep for a considerable length of time.  If that CPU has\na callback that the rest of the system is waiting on, the system might\nrun very slowly or (in theory) even hang.\n\nThis commit avoids this problem by having rcu_needs_cpu() give\ntick_nohz_stop_sched_tick() an estimate of when RCU will need the CPU\nto wake back up, which tick_nohz_stop_sched_tick() takes into account\nwhen programming the CPU's wakeup time.  An alternative approach is\nfor rcu_prepare_for_idle() to use hrtimers instead of normal timers,\nbut timers are much more efficient than are hrtimers for frequently\nand repeatedly posting and cancelling a given timer, which is exactly\nwhat RCU_FAST_NO_HZ does.\n\nReported-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>\nReported-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Paul E. McKenney <paul.mckenney@linaro.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nTested-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nTested-by: Pascal Chapperon <pascal.chapperon@wanadoo.fr>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/22fe38fdca8c9a6eedef3dec4b33d63ee047dae6"},{"sha":"3da2f5dc2ccaa9a9f005ee5f1be8e41ac9a6e02c","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" rcu: Stop rcu_do_batch() from multiplexing the \"count\" variable\n\nCommit b1420f1c (Make rcu_barrier() less disruptive) rearranged the\ncode in rcu_do_batch(), moving the ->qlen manipulation to follow\nthe requeueing of the callbacks.  Unfortunately, this rearrangement\nclobbered the value of the \"count\" local variable before the value\nof rdp->qlen was adjusted, resulting in the value of rdp->qlen being\ninaccurate.  This commit therefore introduces an index variable \"i\",\navoiding the inadvertent multiplexing.\n\nSigned-off-by: Paul E. McKenney <paul.mckenney@linaro.org>\nSigned-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>\nReviewed-by: Josh Triplett <josh@joshtriplett.org>\n\nConflicts:\n\tkernel/rcutree.c","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/3da2f5dc2ccaa9a9f005ee5f1be8e41ac9a6e02c"},{"sha":"d28e8cf06cb934ba4f20ec6f4b7c5333eefb1500","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":"regulator: core: fix race condition in regulator_put() and enable rcu_fast_no_hz\n\ncommit 83b0302d347a49f951e904184afe57ac3723476e upstream.\n\nThe regulator framework maintains a list of consumer regulators\nfor a regulator device and protects it from concurrent access using\nthe regulator device's mutex lock.\n\nIn the case of regulator_put() the consumer is removed and regulator\ndevice's parameters are updated without holding the regulator device's\nmutex. This would lead to a race condition between the regulator_put()\nand any function which traverses the consumer list or modifies regulator\ndevice's parameters.\nFix this race condition by holding the regulator device's mutex in case\nof regulator_put.\n\nSigned-off-by: Ashay Jaiswal <ashayj@codeaurora.org>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/d28e8cf06cb934ba4f20ec6f4b7c5333eefb1500"},{"sha":"8b3518fae34bdf3dc872708a86a42892cf04d5c7","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" net: rps: fix cpu unplug\n\nsoftnet_data.input_pkt_queue is protected by a spinlock that we must\nhold when transferring packets from victim queue to an active one.\nThis is because other cpus could still be trying to enqueue packets\ninto victim queue.\n\nA second problem is that when we transfert the NAPI poll_list from\nvictim to current cpu, we absolutely need to special case the percpu\nbacklog, because we do not want to add complex locking to protect\nprocess_queue : Only owner cpu is allowed to manipulate it, unless\ncpu is offline.\n\nBased on initial patch from Prasad Sodagudi &\nSubash Abhinov Kasiviswanathan.\n\nThis version is better because we do not slow down packet processing,\nonly make migration safer.\n\nReported-by: Prasad Sodagudi <psodagud@codeaurora.org>\nReported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Tom Herbert <therbert@google.com>\nSigned-off-by: Trilok Soni <tsoni@codeaurora.org>\nSigned-off-by: Pranav Vashi <neobuddy89@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/8b3518fae34bdf3dc872708a86a42892cf04d5c7"},{"sha":"9615045356c820cb69d04cb66dcfbe5002225c85","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" timers: Create detach_if_pending() and use it\n\nMost callers of detach_timer() have the same pattern around\nthem. Check whether the timer is pending and eventually updating\nbase->next_timer.\n\nCreate detach_if_pending() and replace the duplicated code.\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Gilad Ben-Yossef <gilad@benyossef.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nLink: http://lkml.kernel.org/r/20120525214819.131246037@linutronix.de\n\nConflicts:\n\tkernel/timer.c","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/9615045356c820cb69d04cb66dcfbe5002225c85"},{"sha":"a09c26f4b5a939a4ab0cfcf473e7f3c37eb9cf27","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" timers: Add accounting of non deferrable timers\n\nThe code in get_next_timer_interrupt() is suboptimal as it has to run\nthrough the cascade to find the next expiring timer. On a completely\nidle core we should only do that when there is an active timer\nenqueued and base->next_timer does not give us a fast answer.\n\nAdd accounting of the active timers to the now consolidated\nattach/detach code. I deliberately avoided sanity checks because the\ncode is fully symetric and any fiddling with timers w/o using the API\nfunctions will lead to cute explosions anyway. ulong is big enough\neven on 32bit and if we really run into the situation to have more\nthan 1<<32 timers enqueued there, then we are definitely not in a\nstate to go idle and run through that code.\n\nThis allows us to fix another shortcoming of get_next_timer_interrupt().\n\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Gilad Ben-Yossef <gilad@benyossef.com>\nCc: Frederic Weisbecker <fweisbec@gmail.com>\nLink: http://lkml.kernel.org/r/20120525214819.236377028@linutronix.de","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/a09c26f4b5a939a4ab0cfcf473e7f3c37eb9cf27"},{"sha":"f1c77874e2f6043b54755c21d226d4f8c46a15af","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" timer: Generalize timer->base flags handling\n\nTo prepare for addition of another flag, generalize timer->base flags\nhandling.\n\n* Rename from TBASE_*_FLAG to TIMER_* and make them LU constants.\n\n* Define and use TIMER_FLAG_MASK for flags masking so that multiple\n  flags can be handled correctly.\n\n* Don't dereference timer->base directly even if\n  !tbase_get_deferrable().  All two such places are already passed in\n  @base, so use it instead.\n\n* Make sure tvec_base's alignment is large enough for timer->base\n  flags using BUILD_BUG_ON().\n\nSigned-off-by: Tejun Heo <tj@kernel.org>\nCc: torvalds@linux-foundation.org\nCc: peterz@infradead.org\nLink: http://lkml.kernel.org/r/1344449428-24962-2-git-send-email-tj@kernel.org\nSigned-off-by: Thomas Gleixner <tglx@linutronix.de>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/f1c77874e2f6043b54755c21d226d4f8c46a15af"},{"sha":"3dcc62dcdfcb2f6e27c56e8f78ab474abd5dd90a","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" ext4: optimize test_root()\n\nThe test_root() function could potentially loop forever due to\noverflow issues.  So rewrite test_root() to avoid this issue; as a\nbonus, it is 38% faster when benchmarked via a test loop:\n\nint main(int argc, char **argv)\n{\n\tint  i;\n\n\tfor (i = 0; i < 1 << 24; i++) {\n\t\tif (test_root(i, 7))\n\t\t\tprintf(\"%d\\n\", i);\n\t}\n}\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/3dcc62dcdfcb2f6e27c56e8f78ab474abd5dd90a"},{"sha":"2f7fde1cf997a5df4508d524dac1d2a4b2bd5f12","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" ext4: get rid of code duplication\n\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Dmitry Monakhov <dmonakhov@openvz.org>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/2f7fde1cf997a5df4508d524dac1d2a4b2bd5f12"},{"sha":"5989612d101af7d06ccf9b2385509f2fdea125e8","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" ext4: optimize starting extent in ext4_ext_rm_leaf()\n\nBoth hole punch and truncate use ext4_ext_rm_leaf() for removing\nblocks.  Currently we choose the last extent as the starting\npoint for removing blocks:\n\n\tex = EXT_LAST_EXTENT(eh);\n\nThis is OK for truncate but for hole punch we can optimize the extent\nselection as the path is already initialized.  We could use this\ninformation to select proper starting extent.  The code change in this\npatch will not affect truncate as for truncate path[depth].p_ext will\nalways be NULL.\n\nSigned-off-by: Ashish Sangwan <a.sangwan@samsung.com>\nSigned-off-by: Namjae Jeon <namjae.jeon@samsung.com>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/5989612d101af7d06ccf9b2385509f2fdea125e8"},{"sha":"e4daef85f908b9f2158be7bee73a4a252320f6bc","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" kthread: make kthread_create() killable\n\nAny user process callers of wait_for_completion() except global init\nprocess might be chosen by the OOM killer while waiting for completion()\ncall by some other process which does memory allocation.  See\nCVE-2012-4398 \"kernel: request_module() OOM local DoS\" can happen.\n\nWhen such users are chosen by the OOM killer when they are waiting for\ncompletion() in TASK_UNINTERRUPTIBLE, the system will be kept stressed\ndue to memory starvation because the OOM killer cannot kill such users.\n\nkthread_create() is one of such users and this patch fixes the problem\nfor kthreadd by making kthread_create() killable - the same approach\nused for fixing CVE-2012-4398.\n\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nCc: Oleg Nesterov <oleg@redhat.com>\nAcked-by: David Rientjes <rientjes@google.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/Tkkg1994/Hulk-Kernel-V2/commits/e4daef85f908b9f2158be7bee73a4a252320f6bc"},{"sha":"648f49d51285a72a34b1b46530ade445aa6045bc","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" kthread: ensure locality of task_struct allocations\n\nIn the presence of memoryless nodes, numa_node_id() will return the\ncurrent CPU's NUMA node, but that may not be where we expect to allocate\nfrom memory from.  Instead, we should rely on the fallback code in the\nmemory allocator itself, by using NUMA_NO_NODE.  Also, when calling\nkthread_create_on_node(), use the nearest node with memory to the cpu in\nquestion, rather than the node it is running on.\n\nSigned-off-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>\nReviewed-by: Christoph Lameter <cl@linux.com>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: Anton Blanchard <anton@samba.org>\nCc: Tejun Heo <tj@kernel.org>\nCc: Oleg Nesterov <oleg@redhat.com>\nCc: Jan Kara <jack@suse.cz>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nCc: Wanpeng Li <liwanp@linux.vnet.ibm.com>\nCc: Joonsoo Kim <iamjoonsoo.kim@lge.com>\nCc: Ben Herrenschmidt <benh@kernel.crashing.org>\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/Tkkg1994/Hulk-Kernel-V2/commits/648f49d51285a72a34b1b46530ade445aa6045bc"},{"sha":"08e06ade8452659c7ee49edc040beeba4267d0b0","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" kthread: fix return value of kthread_create() upon SIGKILL.\n\nCommit 786235eeba0e (\"kthread: make kthread_create() killable\") meant\nfor allowing kthread_create() to abort as soon as killed by the\nOOM-killer.  But returning -ENOMEM is wrong if killed by SIGKILL from\nuserspace.  Change kthread_create() to return -EINTR upon SIGKILL.\n\nSigned-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>\nCc: Oleg Nesterov <oleg@redhat.com>\nAcked-by: David Rientjes <rientjes@google.com>\nCc: <stable@vger.kernel.org> [3.13+]\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/Tkkg1994/Hulk-Kernel-V2/commits/08e06ade8452659c7ee49edc040beeba4267d0b0"},{"sha":"3f24165339673aea358d09d4d99763d2ce7da960","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" 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)\n\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%\n\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\n    master\n\ncommit 46898611ad21b103e22f7dd1468f3db97c2c71bb 1 parent cc13c95\nMichael Wang authored on 4 Jul 2013\ngoogyanas committed 23 days ago\nShowing\nwith 50 additions and 0 deletions.\n3  include/linux/sched.h\n@@ -1235,6 +1235,9 @@ struct task_struct {\nstruct llist_node wake_entry;\nint on_cpu;\n+ struct task_struct *last_wakee;\n+ unsigned long wakee_flips;\n+ unsigned long wakee_flip_decay_ts;\nint on_rq;\n47  kernel/sched/fair.c\n@@ -2344,26 +2344,43 @@\nif (type == 0 || !sched_feat(LB_BIAS))\nreturn total;\nreturn max(rq->cpu_load[type-1], total);\n}\nstatic unsigned long power_of(int cpu)\n{\nreturn cpu_rq(cpu)->cpu_power;\n}\nstatic unsigned long cpu_avg_load_per_task(int cpu)\n{\nstruct rq *rq = cpu_rq(cpu);\nunsigned long nr_running = ACCESS_ONCE(rq->nr_running);\nif (nr_running)\nreturn rq->load.weight / nr_running;\nreturn 0;\n}\n+static void record_wakee(struct task_struct *p)\n+{\n+ /*\n+\t* Rough decay (wiping) for cost saving, don't worry\n+\t* about the boundary, really active task won't care\n+\t* about the loss.\n+\t*/\n+ if (jiffies > current->wakee_flip_decay_ts + HZ) {\n+ current->wakee_flips = 0;\n+ current->wakee_flip_decay_ts = jiffies;\n+ }\n+\n+ if (current->last_wakee != p) {\n+ current->last_wakee = p;\n+ current->wakee_flips++;\n+ }\n+}\nstatic void task_waking_fair(struct task_struct *p)\n{\n@@ -2384,6 +2401,7 @@ static void task_waking_fair(struct task_struct *p)\nse->vruntime -= min_vruntime;\n+ record_wakee(p);\n}\n@@ -2482,26 +2500,48 @@\n/*\n* Recursively apply this logic to all parent groups to compute\n* the final effective load change on the root group. Since\n* only the @tg group gets extra weight, all parent groups can\n* only redistribute existing shares. @wl is the shift in shares\n* resulting from this level per the above.\n*/\nwg = 0;\n}\nreturn wl;\n}\nstatic inline unsigned long effective_load(struct task_group *tg, int cpu,\nunsigned long wl, unsigned long wg)\n{\nreturn wl;\n}\n+static int wake_wide(struct task_struct *p)\n+{\n+ int factor = nr_cpus_node(cpu_to_node(smp_processor_id()));\n+\n+ /*\n+\t* Yeah, it's the switching-frequency, could means many wakee or\n+\t* rapidly switch, use factor here will just help to automatically\n+\t* adjust the loose-degree, so bigger node will lead to more pull.\n+\t*/\n+ if (p->wakee_flips > factor) {\n+ /*\n+\t* wakee is somewhat hot, it needs certain amount of cpu\n+\t* resource, so if waker is far more hot, prefer to leave\n+\t* it alone.\n+\t*/\n+ if (current->wakee_flips > (factor * p->wakee_flips))\n+ return 1;\n+ }\n+\n+ return 0;\n+}\n+\nstatic int wake_affine(struct sched_domain *sd, struct task_struct *p, int sync)\n{\ns64 this_load, load;\nint idx, this_cpu, prev_cpu;\nunsigned long tl_per_task;\nstruct task_group *tg;\nunsigned long weight;\nint balanced;\n+ /*\n+\t* If we wake multiple tasks be careful to not bounce\n+\t* ourselves around too much.\n+\t*/\n+ if (wake_wide(p))\n+ return 0;\n+\nidx = sd->wake_idx;\nthis_cpu = smp_processor_id();\nprev_cpu = task_cpu(p);\n@Tkkg1994\nMarkdown supported\nEdit in fullscreen\nWrite Preview\n\nAttach images by dragging & dropping or selecting them.","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/3f24165339673aea358d09d4d99763d2ce7da960"},{"sha":"52c60b6f52572615516681f3bcf3849b04741344","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" 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>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/52c60b6f52572615516681f3bcf3849b04741344"},{"sha":"f92dff1308e4562dd0b2de2d2fe21d45e818ff7b","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" sched: fix rq->lock recursion\n\nEnabling SCHED_HRTICK currently results in rq->lock recursion and a hard\nhang at bootup.  Essentially try_to_wakeup() grabs rq->lock and tries\narming a hrtimer via hrtimer_restart(), which deep down tries waking up\nksoftirqd, which leads to a recursive call to try_to_wakeup() and thus\nattempt to take rq->lock recursively!!\n\nThis is fixed by having scheduler queue hrtimer via\n__hrtimer_start_range_ns() which avoids waking up ksoftirqd.\n\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\nChange-Id: I11a13be1d9db3a749614ccf3d4f5fb7bf6f18fa1","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/f92dff1308e4562dd0b2de2d2fe21d45e818ff7b"},{"sha":"bf323a8c600d556ff1407e99eb1cfa2615e57206","author":{"email":"dab1ac482cbf0c585f9ac2c32308f0f07e56569c@outlook.com","name":"Tkkg1994"},"message":" sched: Fix SCHED_HRTICK bug leading to late preemption of tasks\n\nSCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot\n(just when they would have exceeded their ideal_runtime). It makes use\nof a a per-cpu hrtimer resource and hence alarming that hrtimer should\nbe based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,\nrather than being based on number of tasks in a particular cfs_rq (as\nimplemented currently). As a result, with current code, its possible for\na running task (which is the sole task in its cfs_rq) to be preempted\nmuch after its ideal_runtime has elapsed, resulting in increased latency\nfor tasks in other cfs_rq on same cpu.\n\nFix this by alarming sched hrtimer based on total number of SCHED_FAIR\ntasks a CPU has across its various cfs_rqs.\n\nChange-Id: I1f23680a64872f8ce0f451ac4bcae28e8967918f\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/Tkkg1994/Hulk-Kernel-V2/commits/bf323a8c600d556ff1407e99eb1cfa2615e57206"}]}