{"push_id":1301718743,"size":12,"distinct_size":12,"ref":"refs/heads/32.2.A.0.253_RyTek-simple","head":"fbcb86200dfa5b6d67dcbdf7f0b98007f7f4211d","before":"97c5a2a20ec2d48d15986e881611788bd8ab0fe6","commits":[{"sha":"ccb2d79ce3f31efa2d6a38e7f6fa9e19f4c0e3eb","author":{"name":"Joonwoo Park","email":"c8d71ca0229c96429b0e81dc3c959fd598c45475@codeaurora.org"},"message":"sched: take into account of governor's frequency max load\n\nAt present HMP scheduler packs tasks to busy CPU till the CPU's load is\n100% to avoid waking up of idle CPU as much as possible.  Such aggressive\npacking leads unintended CPU frequency raise as governor raises the busy\nCPU's frequency when its load is more than configured frequency max load\nwhich can be less than 100%.\n\nFix to take into account of governor's frequency max load and pack tasks\nonly when the CPU's projected load is less than max load to avoid\nunnecessary frequency raise.\n\nChange-Id: I4447e5e0c2fa5214ae7a9128f04fd7585ed0dcac\nSigned-off-by: Joonwoo Park <joonwoop@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/ccb2d79ce3f31efa2d6a38e7f6fa9e19f4c0e3eb"},{"sha":"afd4a7824b1221b53408aac79e2a721efdb5de12","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Pass target_load to scheduler\n\nScheduler needs to understand governor's target_load in order to make\ncorrect decisions when scheduling tasks.\n\nChange-Id: Ia440986de813632def0352e34425fa69da3b2923\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: Joonwoo Park <joonwoop@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/afd4a7824b1221b53408aac79e2a721efdb5de12"},{"sha":"ad1bbf953e532284e9bc87ffcc96a4ccbd37f8c0","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Ignore hispeed_freq logic for notification\n\nWhen governor gets a notification from scheduler, scheduler provides\nexact load that is required by the workload. Ignore hispeed_freq logic\nand directly use choose_freq result for notifications.\n\nAlso use is_notif field to distinguish notifications instead of\nMAX_LOCAL_LOAD.\n\nChange-Id: I409ea66c00f4277adf32d18c339631e1a8b0f97b\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/ad1bbf953e532284e9bc87ffcc96a4ccbd37f8c0"},{"sha":"6588410fb6791e33f7d7d2becb4d880d258af56d","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Fix load in cpufreq_interactive_cpuload event\n\nCPU load is now normalized to per-policy target_load, instead of\ncurrent frequency of CPU. Fix cpufreq_interactive_cpuload accordingly\nso that its load number matches other cpufreq interactive events like\ncpufreq_interactive_target/notyet/already.\n\nChange-Id: I0685b5930ad1bac01819e96fcdfc181167d4dae0\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/6588410fb6791e33f7d7d2becb4d880d258af56d"},{"sha":"fdb0e8311c0bc6a14f06343dca44fe6da5242944","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Allow frequency drop during max_freq_hysteresis\n\nmax_freq_hysteresis keeps CPU at policy->max even after load goes\naway. This is necessary for some workloads where heavy task start and\nstop often. However, in case heavy task indeed stops, it's not very\npower friendly to stay at policy->max for extended period.\n\nInstead of keeping CPU at policy->max, drop frequency optimistically.\nIf a heavy load starts back up again and hit go_hispeed_load within\nmax_freq_hysteresis period, directly ramp back up to policy->max.\n\nChange-Id: I5edf6d765a3599a5b26e13e584bd237e932593f0\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/fdb0e8311c0bc6a14f06343dca44fe6da5242944"},{"sha":"7465e9ec0ea4bdb985b0a92a2bd0bfb4ffd2cafd","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Ramp up to policy->max for heavy new task\n\nNew tasks don't have sufficient history to predict its behavior, even\nwith scheduler's help. Ramping up conservatively for a heavy task\ncould hurt performance when it's needed. Therefore, separate out new\ntasks' load with scheduler's help and ramp up more aggressively if new\ntasks make up a significant portion of total load.\n\nChange-Id: Ia95c956369edb9b7a0768f3bdcb0b2fab367fdf7\nSuggested-by: Saravana Kannan <skannan@codeaurora.org>\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/7465e9ec0ea4bdb985b0a92a2bd0bfb4ffd2cafd"},{"sha":"e370fca420157f191df1f2aba6931f3e6973d251","author":{"name":"Saravana Kannan","email":"1af4e9628f955364122a1d7a403db0e5c0d6f70d@codeaurora.org"},"message":"cpufreq: interactive: Compute target freq independent of policy min/max\n\nWhen the existing code computes the target frequency, it limits the target\nfrequency to be within policy min/max. It does this to make sure the\ngovernor doesn't set the CPU frequency to something outside the policy\nmin/max limits.\n\nThe problem with this is that when the limits are removed, the CPU\nfrequency takes time to catch up with the real load because the governor\nneeds to wait for the next recalculation and even when the recalculated\nfrequency is correct, hysteresis might be applied.\n\nIn reality, the load might have already been consistent enough to exceeded\nthe hysteresis criteria and cause a frequency change if it wasn't for the\npolicy limits. However, since the policy min/max limits the target\nfrequency from reflecting the increased need, the hysteresis criteria\ndoesn't get a chance to expire.\n\nSince the CPUfreq framework already takes care of limiting the governor's\nrequest to be within the policy min/max limits before it sets the CPU\nfrequency, there's no need to limit the computation of target frequency to\nbe within policy min/max.\n\nThat way, when limits are removed, we can use the current target frequency\nas is and immediately jump to a CPU frequency that's appropriate for the\ncurrent load.\n\nChange-Id: Idc02359f6ff91530ff69de8edd8a25c275642099\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/e370fca420157f191df1f2aba6931f3e6973d251"},{"sha":"046de8a1541e429d232ca1f435bffa7ac915e960","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Fix potential divide-by-zero operation\n\nprev_load could be zero if no active time is registered for a CPU\nwithin a sampling period. Fix potential divide-by-zero issue when\ncalculating new load percentage.\n\nChange-Id: I8ad118f5b6b94a410ec59eb5ce939b9467e921c7\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: Hanumath Prasad <hpprasad@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/046de8a1541e429d232ca1f435bffa7ac915e960"},{"sha":"d56a75c6a82f28830242c4744c565a030076c8cd","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Handle notification even if timer fires first\n\nScheduler provides different load number based on whether a\nnotification is pending. Under normal situation, it won't provide a\nload that exceeds 100% busy time of current frequency. For migration,\nthe busy time can be huge if a heavy task just moved to the CPU.\n\nThis creates a race condition due to how governor handles\nnotification:\n1) Scheduler sends notification for a big task\n2) Governor timer runs, and gets a huge load, but fails to skip\nhispeed_freq logic and all delays because it's not a notification\n3) After receiving sched_get_cpus_busy(), scheduler thinks governor has\nfinished handling the notification and changes to provide normal load\nthat is capped to 100% of the CPU at current frequency.\n4) Governor now starts handling notification, but gets a small load\nthat doesn't reflect real demand of the heavy task.\n\nThe migration notification is thus effectively lost. Fixing this by\nmaking notification pending a per-cpu flag. If timer gets ahead of\nnotification handling, it will be run as if it's a notification.\n\nChange-Id: Ie3d68edf85b822232a646c2694bec6928a2d7cd1\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/d56a75c6a82f28830242c4744c565a030076c8cd"},{"sha":"fdbde20c0f6260a28a7d9902ff57ca5a6e1c02ec","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: interactive: Use wake_up_process_no_notif to wake up tasks\n\nScheduler could send a notification to governor each time a task wakes\nup. If governor wakes up another task as a response to such a\nnotification, it could result in endless recursive notifications.\n\nUse wake_up_process_no_notif to ensure scheduler won't send another\nnotification for speedchange task woken up by the governor.\n\nChange-Id: I697affcbdf79e2ad0cfe843eb880d304960682f4\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/fdbde20c0f6260a28a7d9902ff57ca5a6e1c02ec"},{"sha":"649327e86b3b60df7593e1cb664342583b42d8e6","author":{"name":"Junjie Wu","email":"0075153510835c15ef43801605ef8726aea51938@codeaurora.org"},"message":"cpufreq: qcom-cpufreq: Check return of cpufreq_frequency_get_table\n\ncpufreq_frequency_get_table could return NULL. Do error check on the\nreturn value instead of continue with a potentially NULL pointer.\n\nChange-Id: I0cb8a3a8ae3499e738683e5f45271aeadee488f6\nSigned-off-by: Junjie Wu <junjiew@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/649327e86b3b60df7593e1cb664342583b42d8e6"},{"sha":"fbcb86200dfa5b6d67dcbdf7f0b98007f7f4211d","author":{"name":"Saravana Kannan","email":"1af4e9628f955364122a1d7a403db0e5c0d6f70d@codeaurora.org"},"message":"cpufreq: Fix race between policy initialization and cpufreq_cpu_get()\n\nWhen the first CPU in a policy comes online or is brought up for the first\ntime, a policy is allocated for it. However, the kobject corresponding to\nit is not allocated until later. So, if cpufreq_cpu_get() is called in\nthis interval, it would try to \"get\" an uninitialized kobject. Avoid this\nby allocating the kobject at the same time as allocating the policy.\n\nChange-Id: I676408da41e3feccb85b74e2a4a23f3a1f6892bd\nSigned-off-by: Saravana Kannan <skannan@codeaurora.org>\nSigned-off-by: RyTek <rytek1128@outlook.com>","distinct":true,"url":"https://api.github.com/repos/RyTekk/sony_kernel_kitakami_8994/commits/fbcb86200dfa5b6d67dcbdf7f0b98007f7f4211d"}]}
{"actor":{"display_login":"RyTekk"}}