{"push_id":910986065,"size":26,"distinct_size":26,"ref":"refs/heads/extra","head":"bf9e71d13dbeb439990b2f75ed2296ab55016965","before":"079907aac7f1eee94a06c4f766a2c22fecde4793","commits":[{"sha":"bf8d12e30fc0eb932dc5ab3217a34b1f9022cf25","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"Added fsync on/off support.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/bf8d12e30fc0eb932dc5ab3217a34b1f9022cf25"},{"sha":"1b6ed950edb33d0277fac83bdf85050a2d05fd25","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"Francisco Franco"},"message":"fs: sync: add missing return if fsync is disabled from userspace.\n\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/1b6ed950edb33d0277fac83bdf85050a2d05fd25"},{"sha":"282233714deab126ddfdcc9f14356c0aa40e93b5","author":{"email":"b3db597eb8bb7f6a166202c1f96550c548e388c9@gmail.com","name":"nikhil18"},"message":"KGSL: GPU kgsl_pwrctrl.c use min pwr level as default. to reduce battery drain","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/282233714deab126ddfdcc9f14356c0aa40e93b5"},{"sha":"42eb58d3865a4fc022c3d9a19518819e28cac4a7","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"tick: don't update idle time if cpu offline\n\nAn offline cpu still has ts->idle_active == 1, that cause\noff time is counted as idle time, and hence cause cpu load\ncalculated wrongly.\n\nCheck the cpu online status before updating the idle time to\nfix it.\n\nChange-Id: I00deb4cbcaec18f7625ee774bf4c3e643330dd5f\nSigned-off-by: Lianwei Wang <a22439@motorola.com>\nReviewed-on: http://gerrit.mot.com/695764\nSLTApproved: Slta Waiver <sltawvr@motorola.com>\nTested-by: Jira Key <jirakey@motorola.com>\nReviewed-by: Christopher Fries <cfries@motorola.com>\nReviewed-by: Igor Kovalenko <igork@motorola.com>\nSubmit-Approved: Jira Key <jirakey@motorola.com>\n[picked from http://goo.gl/lLF51X]\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/42eb58d3865a4fc022c3d9a19518819e28cac4a7"},{"sha":"dbe931815d2b6c17facf9ed6148389eda5ee6922","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"mako_hotplug: add my CPU Hotplug driver\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/dbe931815d2b6c17facf9ed6148389eda5ee6922"},{"sha":"6969a0548e57c9cdde65c02b4bcda5b24f5bc7ad","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"cpufreq: create a helper function to get CPU utilization. Picked from @stratosk\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/6969a0548e57c9cdde65c02b4bcda5b24f5bc7ad"},{"sha":"659e17689bdc8479528ff910585ff61816ec2bdf","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"msm: slimbus: use interruptible wait to reduce system's load average\n\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/659e17689bdc8479528ff910585ff61816ec2bdf"},{"sha":"96a806a70585190f4ea3d048ce00ae487389e24a","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"franciscofranco"},"message":"sched/fair: Implement fast idling of CPUs when the system is partially loaded\n\nWhen a system is lightly loaded (i.e. no more than 1 job per cpu),\nattempt to pull job to a cpu before putting it to idle is unnecessary and\ncan be skipped.  This patch adds an indicator so the scheduler can know\nwhen there's no more than 1 active job is on any CPU in the system to\nskip needless job pulls.\n\nOn a 4 socket machine with a request/response kind of workload from\nclients, we saw about 0.13 msec delay when we go through a full load\nbalance to try pull job from all the other cpus.  While 0.1 msec was\nspent on processing the request and generating a response, the 0.13 msec\nload balance overhead was actually more than the actual work being done.\nThis overhead can be skipped much of the time for lightly loaded systems.\n\nWith this patch, we tested with a netperf request/response workload that\nhas the server busy with half the cpus in a 4 socket system.  We found\nthe patch eliminated 75% of the load balance attempts before idling a cpu.\n\nThe overhead of setting/clearing the indicator is low as we already gather\nthe necessary info while we call add_nr_running() and update_sd_lb_stats.()\nWe switch to full load balance load immediately if any cpu got more than\none job on its run queue in add_nr_running.  We'll clear the indicator\nto avoid load balance when we detect no cpu's have more than one job\nwhen we scan the work queues in update_sg_lb_stats().  We are aggressive\nin turning on the load balance and opportunistic in skipping the load\nbalance.\n\nSigned-off-by: Tim Chen <tim.c.chen@linux.intel.com>\nAcked-by: Rik van Riel <riel@redhat.com>\nAcked-by: Jason Low <jason.low2@hp.com>\nCc: \"Paul E.McKenney\" <paulmck@linux.vnet.ibm.com>\nCc: Andrew Morton <akpm@linux-foundation.org>\nCc: Davidlohr Bueso <davidlohr@hp.com>\nCc: Alex Shi <alex.shi@linaro.org>\nCc: Michel Lespinasse <walken@google.com>\nCc: Peter Hurley <peter@hurleysoftware.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/1403551009.2970.613.camel@schen9-DESK\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n(backport to 3.4)\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\n\nConflicts:\n\tkernel/sched/sched.h","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/96a806a70585190f4ea3d048ce00ae487389e24a"},{"sha":"5216e955fe3576e1a62eb85d1254e9f5b10d5796","author":{"email":"f2a4cf793007be8f81a774dc7806c1ffea7b4a2c@intel.com","name":"Zhang Rui"},"message":"PM: Introduce suspend state PM_SUSPEND_FREEZE\n\nPM_SUSPEND_FREEZE state is a general state that\ndoes not need any platform specific support, it equals\nfrozen processes + suspended devices + idle processors.\n\nCompared with PM_SUSPEND_MEMORY,\nPM_SUSPEND_FREEZE saves less power\nbecause the system is still in a running state.\nPM_SUSPEND_FREEZE has less resume latency because it does not\ntouch BIOS, and the processors are in idle state.\n\nCompared with RTPM/idle,\nPM_SUSPEND_FREEZE saves more power as\n1. the processor has longer sleep time because processes are frozen.\n   The deeper c-state the processor supports, more power saving we can get.\n2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get\n   more power saving from the devices that does not have good RTPM support.\n\nThis state is useful for\n1) platforms that do not have STR, or have a broken STR.\n2) platforms that have an extremely low power idle state,\n   which can be used to replace STR.\n\nThe following describes how PM_SUSPEND_FREEZE state works.\n1. echo freeze > /sys/power/state\n2. the processes are frozen.\n3. all the devices are suspended.\n4. all the processors are blocked by a wait queue\n5. all the processors idles and enters (Deep) c-state.\n6. an interrupt fires.\n7. a processor is woken up and handles the irq.\n8. if it is a general event,\n   a) the irq handler runs and quites.\n   b) goto step 4.\n9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,\n   a) the irq handler runs and activate the wakeup source\n   b) wakeup_source_activate() notifies the wait queue.\n   c) system starts resuming from PM_SUSPEND_FREEZE\n10. all the devices are resumed.\n11. all the processes are unfrozen.\n12. system is back to working.\n\nKnown Issue:\nThe wakeup of this new PM_SUSPEND_FREEZE state may behave differently\nfrom the previous suspend state.\nTake ACPI platform for example, there are some GPEs that only enabled\nwhen the system is in sleep state, to wake the system backk from S3/S4.\nBut we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.\nThis means we may lose some wake event.\nBut on the other hand, as we do not disable all the Interrupts during\nPM_SUSPEND_FREEZE, we may get some extra \"wakeup\" Interrupts, that are\nnot available for S3/S4.\n\nThe patches has been tested on an old Sony laptop, and here are the results:\n\nAverage Power:\n1. RPTM/idle for half an hour:\n   14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W\n2. Freeze for half an hour:\n   11W, 10.4W, 9.4W, 11.3W 10.5W\n3. RTPM/idle for three hours:\n   11.6W\n4. Freeze for three hours:\n   10W\n5. Suspend to Memory:\n   0.5~0.9W\n\nAverage Resume Latency:\n1. RTPM/idle with a black screen: (From pressing keyboard to screen back)\n   Less than 0.2s\n2. Freeze: (From pressing power button to screen back)\n   2.50s\n3. Suspend to Memory: (From pressing power button to screen back)\n   4.33s\n\n>From the results, we can see that all the platforms should benefit from\nthis patch, even if it does not have Low Power S0.\n\nSigned-off-by: Zhang Rui <rui.zhang@intel.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>\n\nConflicts:\n\tkernel/power/main.c\n\tkernel/power/suspend.c\n\nConflicts:\n\tkernel/power/suspend.c","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/5216e955fe3576e1a62eb85d1254e9f5b10d5796"},{"sha":"5303049bede2238cfd8e29715e463bf4484c5244","author":{"email":"b7088a9c70345a9ab94cacab3cc3888d0a7dc884@euromail.se","name":"Henrik Rydberg"},"message":"Input: Send events one packet at a time\n\nOn heavy event loads, such as a multitouch driver, the irqsoff latency\ncan be as high as 250 us.  By accumulating a frame worth of data\nbefore passing it on, the latency can be dramatically reduced.  As a\nside effect, the special EV_SYN handling can be removed, since the\nframe is now atomic.\n\nThis patch adds the events() handler callback and uses it if it\nexists. The latency is improved by 50 us even without the callback.\n\nChange-Id: Iebd9b1868ae6300a922a45b6d104e7c2b38e4cf5\nCc: Daniel Kurtz <djkurtz@chromium.org>\nTested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>\nTested-by: Ping Cheng <pingc@wacom.com>\nTested-by: Sedat Dilek <sedat.dilek@gmail.com>\nAcked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Henrik Rydberg <rydberg@euromail.se>\n\nInput: Improve the events-per-packet estimate\n\nThe events-per-packet estimate has so far been used by MT devices\nonly. This patch adjusts the packet buffer size to also accomodate the\nKEY and MSC events.  Keyboards normally send one or two keys at a\ntime. MT devices normally send a number of button keys along with the\nMT information.  The buffer size chosen here covers those cases, and\nmatches the default buffer size in evdev. Since the input estimate is\nnow preferred, remove the special input-mt estimate.\n\nReviewed-and-tested-by: Ping Cheng <pingc@wacom.com>\nTested-by: Benjamin Tissoires <benjamin.tissoires@enac.fr>\nAcked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Henrik Rydberg <rydberg@euromail.se>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>\nSigned-off-by: Francisco Franco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/5303049bede2238cfd8e29715e463bf4484c5244"},{"sha":"2368ce02c9dae98034a030eb600018e377cad935","author":{"email":"bc04d5e582bf5c032c24683f7314bdaab249b0ae@hotmail.com","name":"mrg666"},"message":"af_unix: speedup /proc/net/unix\n/proc/net/unix has quadratic behavior, and can hold unix_table_lock for\na while if high number of unix sockets are alive. (90 ms for 200k\nsockets...)\n\nWe already have a hash table, so its quite easy to use it.\n\nProblem is unbound sockets are still hashed in a single hash slot\n(unix_socket_table[UNIX_HASH_TABLE])\n\nThis patch also spreads unbound sockets to 256 hash slots, to speedup\nboth /proc/net/unix and unix_diag.\n\nTime to read /proc/net/unix with 200k unix sockets :\n(time dd if=/proc/net/unix of=/dev/null bs=4k)\n\nbefore : 520 secs\nafter : 2 secs\n\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nCc: Steven Whitehouse <swhiteho@redhat.com>\nCc: Pavel Emelyanov <xemul@parallels.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/2368ce02c9dae98034a030eb600018e377cad935"},{"sha":"50499d0f3fb57bc883e8160c90d5cafcc1fe1b71","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched: Change rq->nr_running to unsigned int\n\nSince there's a PID space limit of 30bits (see\nfutex.h:FUTEX_TID_MASK) and allocating that many tasks (assuming a\nlower bound of 2 pages per task) would still take 8T of memory it\nseems reasonable to say that unsigned int is sufficient for\nrq->nr_running.\n\nWhen we do get anywhere near that amount of tasks I suspect other\nthings would go funny, load-balancer load computations would really\nneed to be hoisted to 128bit etc.\n\nSo save a few bytes and convert rq->nr_running and friends to\nunsigned int.\n\nSuggested-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-y3tvyszjdmbibade5bw8zl81@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/50499d0f3fb57bc883e8160c90d5cafcc1fe1b71"},{"sha":"69c61713418517253c5f5bfc244a14887f8747a4","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched/fair: Let minimally loaded cpu balance the group\n\nCurrently we let the leftmost (or first idle) cpu ascend the\nsched_domain tree and perform load-balancing. The result is that the\nbusiest cpu in the group might be performing this function and pull\nmore load to itself. The next load balance pass will then try to\nequalize this again.\n\nChange this to pick the least loaded cpu to perform higher domain\nbalancing.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-v8zlrmgmkne3bkcy9dej1fvm@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/69c61713418517253c5f5bfc244a14887f8747a4"},{"sha":"c8497fb92abd061f6540174e05a9e8933726c96d","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched/fair: Add some serialization to the sched_domain load-balance walk\n\nSince the sched_domain walk is completely unserialized (!SD_SERIALIZE)\nit is possible that multiple cpus in the group get elected to do the\nnext level. Avoid this by adding some serialization.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-vqh9ai6s0ewmeakjz80w4qz6@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/c8497fb92abd061f6540174e05a9e8933726c96d"},{"sha":"335b3f6a0a688663ab707dc70acf3a2e3feefe4b","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched/fair: Propagate 'struct lb_env' usage into find_busiest_group\n\nMore function argument passing reduction.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-v66ivjfqdiqdso01lqgqx6qf@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\n(adapter for the recent idle_balance changes)\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/335b3f6a0a688663ab707dc70acf3a2e3feefe4b"},{"sha":"2c95fc2d02eb91da1cfc3424295992608fa46b74","author":{"email":"645ca7d3a8d3d4f60557176cd361ea8351edc32b@chello.nl","name":"Peter Zijlstra"},"message":"sched/fair: Revert sched-domain iteration breakage\n\nPatches c22402a2f (\"sched/fair: Let minimally loaded cpu balance the\ngroup\") and 0ce90475 (\"sched/fair: Add some serialization to the\nsched_domain load-balance walk\") are horribly broken so revert them.\n\nThe problem is that while it sounds good to have the minimally loaded\ncpu do the pulling of more load, the way we walk the domains there is\nabsolutely no guarantee this cpu will actually get to the domain. In\nfact its very likely it wont. Therefore the higher up the tree we get,\nthe less likely it is we'll balance at all.\n\nThe first of mask always walks up, while sucky in that it accumulates\nload on the first cpu and needs extra passes to spread it out at least\nguarantees a cpu gets up that far and load-balancing happens at all.\n\nSince its now always the first and idle cpus should always be able to\nbalance so they get a task as fast as possible we can also do away\nwith the added serialization.\n\nSigned-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>\nLink: http://lkml.kernel.org/n/tip-rpuhs5s56aiv1aw7khv9zkw6@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/2c95fc2d02eb91da1cfc3424295992608fa46b74"},{"sha":"a03cc340e154761200d5c07cff6d85edf4aa02ac","author":{"email":"42480b5f4d505650064e5081b85d867a03559887@gmail.com","name":"Francisco Franco"},"message":"Revert \"sched_avg: add run queue averaging.\"\n\nWe're not using this so lets save calls every time there is run_queue change.\n\nThis reverts commit e163bf662abb0a69aa08ed72885d1fae23a5b8c2.\n\nConflicts:\n\tkernel/sched/sched.h","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/a03cc340e154761200d5c07cff6d85edf4aa02ac"},{"sha":"86a2da270d28f8ffe130706ec74064b469f50a46","author":{"email":"3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","name":"Peter Zijlstra"},"message":"sched/idle: Avoid spurious wakeup IPIs\n\nBecause mwait_idle_with_hints() gets called from !idle context it must\ncall current_clr_polling(). This however means that resched_task() is\nvery likely to send an IPI even when we were polling:\n\n  CPU0\t\t\t\t\tCPU1\n\n  if (current_set_polling_and_test())\n    goto out;\n\n  __monitor(&ti->flags);\n  if (!need_resched())\n    __mwait(eax, ecx);\n\t\t\t\t\tset_tsk_need_resched(p);\n\t\t\t\t\tsmp_mb();\nout:\n  current_clr_polling();\n\t\t\t\t\tif (!tsk_is_polling(p))\n\t\t\t\t\t  smp_send_reschedule(cpu);\n\nSo while it is correct (extra IPIs aren't a problem, whereas a missed\nIPI would be) it is a performance problem (for some).\n\nAvoid this issue by using fetch_or() to atomically set NEED_RESCHED\nand test if POLLING_NRFLAG is set.\n\nSince a CPU stuck in mwait is unlikely to modify the flags word,\ncontention on the cmpxchg is unlikely and thus we should mostly\nsucceed in a single go.\n\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nAcked-by: Nicolas Pitre <nico@linaro.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/n/tip-kf5suce6njh5xf5d3od13rr0@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/86a2da270d28f8ffe130706ec74064b469f50a46"},{"sha":"6c4f1d8bdaf252faa8af77392fd4f0c9061ab786","author":{"email":"f0a29e10abf52e3965939db20f961ffd5c7f3d14@yandex.ru","name":"Kirill Tkhai"},"message":"sched/__wake_up_sync_key(): Fix nr_exclusive tasks which lead to WF_SYNC clearing\n\nOnly one task can replace the waker.\n\nSigned-off-by: Kirill Tkhai <tkhai@yandex.ru>\nCC: Steven Rostedt <rostedt@goodmis.org>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/r/512421372963700@web25f.yandex.ru\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/6c4f1d8bdaf252faa8af77392fd4f0c9061ab786"},{"sha":"a77f2e196c018722480dbd16d35b4477abe21f8e","author":{"email":"6affa2782fb8514898f88c7c4a087191fcbabb20@linux.vnet.ibm.com","name":"Michael Wang"},"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\nSigned-off-by: franciscofranco <franciscofranco.1990@gmail.com>","distinct":true,"url":"https://api.github.com/repos/nikhil18/lightning-kernel-bacon/commits/a77f2e196c018722480dbd16d35b4477abe21f8e"}]}