{"push_id":2052313862,"size":2,"distinct_size":2,"ref":"refs/heads/mainline","head":"be428e63d5adbcc2f4375c2193b506f2b8e5869f","before":"40402e7dca0f86af2d3705f4a7e9f74024b2d1c7","commits":[{"sha":"c5ac45df5e4a8f4053afc9d9e05f37ae67124075","author":{"name":"Srivatsa Vaddagiri","email":"4ebad9f61da157750c36beb638e9bb3384814e5d@codeaurora.org"},"message":"sched: Introduce SCHED_FREQ_INPUT\n\nsched: Make scheduler aware of cpu frequency state\n\nCapacity of a cpu (how much performance it can deliver) is partly\ndetermined by its frequency (P) state, both current frequency as well\nas max frequency it can reach.  Knowing frequency state of cpus will\nhelp scheduler optimize various functions such as tracking every\ntask's cpu demand and placing tasks on various cpus.\n\nThis patch has scheduler registering for cpufreq notifications to\nbecome aware of cpu's frequency state. Subsequent patches will make\nuse of derived information for various purposes, such as task's scaled\nload (cpu demand) accounting and task placement.\n\nChange-Id: I376dffa1e7f3f47d0496cd7e6ef8b5642ab79016\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\nsched: Window-based load stats for tasks\n\nProvide a metric per task that specifies how cpu bound a task is. Task\nexecution is monitored over several time windows and the fraction of\nthe window for which task was found to be executing or wanting to run\nis recorded as task's demand. Windows over which task was sleeping are\nignored. We track last 5 recent windows for every task and the maximum\ndemand seen in any of the previous 5 windows (where task had some\nactivity) drives freq demand for every task.\n\nA per-cpu metric (rq->cumulative_runnable_avg) is also provided which\nis an aggregation of cpu demand of all tasks currently enqueued on it.\nrq->cumulative_runnable_avg will be useful to know if cpu frequency\nwill need to be changed to match task demand.\n\nChange-Id: Ib83207b9ba8683cd3304ee8a2290695c34f08fe2\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\nsched: Call the notify_on_migrate notifier chain for wakeups as well\n\nAdd a change to send notify_on_migrate hints on wakeups of\nforeground tasks from scheduler if their load is above\nwakeup_load_thresholds (default value is 60).\nThese hints can be used to choose an appropriate CPU frequency\ncorresponding to the load of the task being woken up.\n\nChange-Id: Ieca413c1a8bd2b14a15a7591e8e15d22925c42ca\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\nsched: Disable wakeup hints for foreground tasks by default\n\nBy default sched_wakeup_load_threshold is set to 60 and therefore\nwakeup hints are sent out for those tasks whose loads are higher\nthat value. This might cause unnecessary wakeup boosts to happen\nwhen load based syncing is turned ON for cpu-boost.\nDisable the wake up hints by setting the sched_wakeup_load_threshold\nto a value higher than 100 so that wakeup boost doesnt happen unless\nit is explicitly turned ON from adb shell.\n\nChange-Id: I9b8a594c2bfdf2e092cc645e50c0c21efc514c2f\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\nsched: Window-based load stat improvements\n\nSome tasks can have a sporadic load pattern such that they can suddenly\nstart running for longer intervals of time after running for shorter\ndurations. To recognize such sharp increase in tasks' demands, max\nbetween the average of 5 window load samples and the most recent sample\nis chosen as the task demand.\n\nMake the window size (sched_ravg_window) configurable at boot up\ntime. To prevent users from setting inappropriate values for window\nsize, min and max limits are defined. As 'ravg' struct tracks load for\nboth real-time and non real-time tasks it is moved out of sched_entity\nstruct.\n\nIn order to prevent changing function signatures for move_tasks() and\nmove_one_task() per-cpu variables are defined to track the total load\nmoved. In case multiple tasks are selected to migrate in one load\nbalance operation, loads > 100 could be sent through migration notifiers.\nPrevent this scenario by setting mnd.load to 100 in such cases.\n\nDefine wrapper functions to compute cpu demands for tasks and to change\nrq->cumulative_runnable_avg.\n\nChange-Id: I9abfbf3b5fe23ae615a6acd3db9580cfdeb515b4\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\nsched: window-stats: Fix overflow bug\n\nMultiplication over-flow possibility exists in update_task_ravg() when\nupdating task's window_start. That would lead to incorrect accounting\nof task load. Fix the issue by using 64-bit arithmetic.\n\nCRs-Fixed: 665706\nChange-Id: I92651c41efa6121bb8fe102e495ae956127b237a\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\nsched: Skip load update for idle task\n\nLoad statistics for idle tasks is not useful in any manner. Skip load\nupdate for such idle tasks.\n\nCRs-Fixed: 665706\nChange-Id: If3a908bad7fbb42dcb3d0a1d073a3750cf32fcf9\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\nsched: move task load based functions\n\nThe task load based functions will need to make use of LOAD_AVG_MAX\nin a subsequent patch, so move them below the definition of that\nmacro.\n\nChange-Id: I02f18ba069b81033e611f8f8bba6dccd7cd81252\nSigned-off-by: Steve Muckle <smuckle@codeaurora.org>\n\nsched: Add min_max_freq and rq->max_possible_freq\n\nrq->max_possible_freq represents the maximum frequency a cpu is\ncapable of attaining, while rq->max_freq represents the maximum\nfrequency a cpu can attain at a given instant. rq->max_freq includes\nconstraints imposed by user or thermal driver.\nrq->max_freq <= rq->max_possible_freq.\n\nmax_possible_freq is derived as max(rq->max_possible_freq) and\nrepresents the \"best\" cpu that can attain best possible frequency.\n\nmin_max_freq is derived as min(rq->max_possible_freq). For homogeneous\nsystems, max_possible_freq and min_max_freq will be same, while they\ncould be different on heterogeneous systems.\n\nChange-Id: Iec485fde35cfd33f55ebf2c2dce4864faa2083c5\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\nsched: window-based load stats improvements\n\nFollowing cleanups and improvements are made to window-based load\nstats feature:\n\n* Add sysctl to pick max, avg or most recent samples as task's\n  demand.\n\n* Fix overflow possibility in calculation of sum for average policy.\n\n* Use unscaled statistics when a task is running on a CPU which is\nthermally throttled.\n\nChange-Id: I8293565ca0c2a785dadf8adb6c67f579a445ed29\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>","distinct":true,"url":"https://api.github.com/repos/alesaiko/breakfast-hammerhead/commits/c5ac45df5e4a8f4053afc9d9e05f37ae67124075"},{"sha":"be428e63d5adbcc2f4375c2193b506f2b8e5869f","author":{"name":"Saravana Kannan","email":"1af4e9628f955364122a1d7a403db0e5c0d6f70d@codeaurora.org"},"message":"cpufreq: Add cpu-boost driver\n\nWhen certain bursty and important events take place, it might take a while\nfor the current cpufreq governor to notice the new load and react to it.\nThat would result in poor user experience. To alleviate this, the cpu-boost\ndriver boosts the frequency of a CPU for a short duration to maintain good\nuser experience while the governor catches up.\n\nSpecifically, this commit deals with ensuring that when \"important\" tasks\nmigrate from a fast CPU to a slow CPU, the frequency of the slow CPU is\nboosted to be at least as high as the fast CPU for a short duration.\n\nSince this driver enforces the boost by hooking into standard cpufreq\nADJUST notifiers, it has several advantages:\n- More portable across kernel versions where the cpufreq internals might\n  have been rewritten.\n- Governor agnostic and hence works with multiple governors like\n  conservative, ondemand, interactive, etc.\n- Does not affect the sampling period/logic of existing governors.\n- Can have the boost period adjusted independent of governor sampling\n  period.\n\ncpufreq: Remove frequency synchronization and input boosting from ondemand\n\nCPU-Boost now handles frequency synchronization between source and\ntarget cpus during task migrations on its own. Additional algorithms\nwill cause a race that will most likely lead to a frequency imbalance\nand kernel panic.\n\nThe same is true for input boosting.\n\nCompletely remove frequency synchronization and input boosting\nmechanisms from ondemand cpufreq governor.\n\nChange-Id: Ibd814a20043d0aba64ee7637a4a79b9ffa1b0991\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ncpufreq: Add a sync limit to cpu-boost\n\nPerform frequency synchronization only when source CPU's frequency\nis less than sync_threshold, else sync to the sync_threshold.\n\nChange-Id: I544c414568d4e015b80ce5891dd215275bac95da\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\ncpufreq: Add Input Boost feature to the cpu-boost driver\n\nOn incoming input events boost the frequency of all online cpus\nfor at least input_boost_ms ms. This is accomplished by changing\nthe policy->min of all the online cpus to input_boost_freq.\n\nChange-Id: Idb0ab75d68ae4ceff259cbbaaec1a9bb3bc871d3\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\ncpufreq: Disable cpu-boost by default\n\nDisable cpu-boost by default, so that it can be turned ON only by\nsetting the module parameter boost_ms through command prompt when\nrequired.\n\nChange-Id: Ia9bc280892f65ed1d2e8051d1951e51922ad13db\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\ncpufreq: cpu-boost: Fix queue_delayed_work_on() race with hotplug\n\nCalling queue_delayed_work_on() on a CPU that's in the process of getting\nhotplugged out can result in that CPU infinitely looping in\nmsm_pm_wait_cpu_shutdown(). If queue_delayed_work_on() is called after the\nCPU is hotplugged out, it could wake up the CPU without going through the\nhotplug path and cause instability. To avoid this, make sure the CPU is and\nstays online while queuing a work on it.\n\nChange-Id: I1b4aae3db803e476b1a7676d08f495c1f38bb154\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ncpufreq: cpu-boost: Fix deadlock in wake_up of sync threads\n\nIf wake_up() is called on the current task on a CPU, the call will wait\nuntil the current task is switched out before it wakes it up again and\nreturns.\n\nThe sync notifier for a CPU always runs on that CPU.\n\nThese two together can result in a deadlock if the sync notifier on CPU A\ntries to wake up the sync thread of CPU A as it goes to sleep (is the\ncurrent task). A previous commit fixed this by adding a check to the sync\nnotifier to not wake up the sync thread of CPU A if it's the current task.\n\nBut this is still not sufficient to prevent deadlocks.\n\nSync thread of CPU A could be the current task on CPU B and sync thread of\nCPU B could be the current task on CPU A.  At this point, if sync notifier\nof CPU A and B try to wake up the sync threads of CPU A and B, it will\nresult in CPU A waiting for the current task in CPU B to get switched out\nand CPU B waiting for the current task in CPU A to get switched out.  This\nwill result in a deadlock.\n\nPrevent this scenario from happening by pinning the sync threads of each\nCPU to run on that CPU. By doing this, we guarantee that sync notifiers\nwill only try to wake up sync threads running on that CPU. The fix added by\n\"cpufreq: cpu-boost: Resolve deadlock when waking up sync thread\" ensures a\ndeadlock doesn't happen when a sync notifier tries to wake up a sync thread\nrunning on that CPU.\n\nChange-Id: I864e545529722a23886dd5a82f66089155d2d193\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ncpufreq: cpu-boost: Don't register for cpufreq notifiers too early\n\nThe cpufreq notifiers should be registered only after all the data\nstructures used in the notifier callbacks have been initialized. So, move\nthe cpufreq notifier registration to a later point in the init function.\n\nChange-Id: I043ab5bc0ebb98164c40549fe151a8d801c8c186\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\n\ncpufreq: cpu-boost: Use interruptible wait to not affect load average\n\nUsing the function wait_event in cpu_boost puts the\nprocess enter to 'D' state which contribute to the\nhigh load average. This change will put the process\nboost_sync in the 'S' state (interruptible sleep).\n\nCRs-Fixed: 655484\nChange-Id: Ie121adbe1fac1d2862ac5342bb97c7c926f7d7a8\nSigned-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>\n\ncpufreq: cpu-boost: Resolve deadlock when waking up sync thread\n\nCPU boost driver receives notification from scheduler when threads\nmigrate towards a cpu and in turn wakes up a sync thread associated\nwith that cpu to handle any required frequency transitions. The wakeup\ncall however can lead to a deadlock inside scheduler under some\ncircumstance. The deadlock is seen when sync thread is the only thread\nrunning on a cpu and goes to sleep (say by calling wait_event() ->\nschedule()). Midway through this sleep (schedule()) call, while cpu is\nstill running in context of sync thread, scheduler attempts a load\nbalance (realizing that cpu is about to become idle) which can result\nin tasks being migrated towards the cpu going idle. This will cause\nmigration notification to be issued and in turn a wakeup on sync\nthread. The wakeup call however gets stuck in below while() loop\ninside scheduler:\n\ntry_to_wake_up(struct task_struct *p, ...)\n{\n\n        /*\n         * If the owning (remote) cpu is still in the middle of\n         * schedule() with this task as prev, wait until its done\n         * referencing the task.\n         */\n        while (p->on_cpu)\n                cpu_relax();\n\n}\n\nA possible fix could be to teach try_to_wake_up() about this\nspecial case. Another fix, implemented in this patch and that helps\nminimize scheduler changes, is to have cpu boost driver not issue a\nwakeup under this special circumstance, which was found to occur very\ninfrequently.\n\nChange-Id: I92bc68a22d51595a208673fe2a1eedfa97004f9e\nSigned-off-by: Srivatsa Vaddagiri <vatsa@codeaurora.org>\n\ncpufreq: cpu-boost: Re-issue boosts above minimum frequency\n\nFrequency boosts where the source CPU frequency is greater than CPU's\nminimum frequency should always go through regardless of the destination\nCPU's current frequency. This fixes a performance issue where the governor\nlowers the CPU frequency shortly after a thread is migrated to it because\nthe boost wasn't re-issued.\n\nChange-Id: I449545a688d84b0a6e834f5a51dcb499caa84d29\nSigned-off-by: Patrick Cain <pcain@codeaurora.org>\n\ncpufreq: cpu-boost: Resolve deadlock when waking up sync thread\n\nWaking up sync thread recursively for same CPU causes deadlock.\nFix this by avoiding recursive wakeup call to same thread.\n\nCRs-Fixed: 814956\nChange-Id: Iaa789bc8a441e56524e0851274765a07937d83fb\nSigned-off-by: Swetha Chikkaboraiah <schikk@codeaurora.org>\n\ncpufreq: Sync on thread migration optimizations\n\nWhen threads migrate between CPUs the destination CPU will temporarily\nhave a boosted frequency and the source CPU will have a residual higher\nfrequency even though the load could have just been reduced. To avoid\nleaving CPUs at a high frequencies notify the source CPU after a thread\nmigration and make the interactive governor's timer reschedule\nconditionally.\n\nChange-Id: Id55055f2a116ca7ffd2a34dc3d0ec519c888a111\nSigned-off-by: Patrick Cain <pcain@codeaurora.org>\n\ncpufreq: cpu-boost: Support separate input_boost_freq for different CPUs\n\nDifferent types of CPUs could have different frequency to satisfy same\ninput workload. Add support for using different input_boost_freq on\ndifferent CPUs.\n\ninput_boost_freq now either takes a single number which applies to all\nCPUs, or cpuid:freq pairs separated by space for different CPUs.\n\nChange-Id: I20506a9fbdb4d532d94168bbd61744595bebc8e5\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\n\ncpufreq: cpu-boost: Use one work to remove input boost for all CPUs\n\nCurrently each CPU queues up its own work for removing input boost.\nThis is not really required as boost removal for all the CPUs can\nbe done at the same time. So this patch uses a single work to\nremove input boost for all the CPUs and updates the policy for\nthe online ones.\n\nChange-Id: I37c809f2f155548b1d8c1b9aa7626c8852b3acc6\nSigned-off-by: Rohit Gupta <rohgup@codeaurora.org>\n\ncpufreq: cpu-boost: Return early if no input boost duration is set\n\nChange-Id: I219ddf4d3e4afb5536a5639893b9b40c701db6a6","distinct":true,"url":"https://api.github.com/repos/alesaiko/breakfast-hammerhead/commits/be428e63d5adbcc2f4375c2193b506f2b8e5869f"}]}
{"actor":{"display_login":"alesaiko"}}