Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1603976 > unrolled thread
| Started by | "Rafael J. Wysocki" <rjw@rjwysocki.net> |
|---|---|
| First post | 2017-03-19 14:50 +0100 |
| Last post | 2017-03-27 23:20 +0200 |
| Articles | 5 on this page of 65 — 8 participants |
Back to article view | Back to linux.kernel
[PATCH 0/2] cpufreq: schedutil: Fix and optimization "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-19 14:50 +0100
[PATCH 1/2] cpufreq: schedutil: Fix per-CPU structure initialization in sugov_start() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-19 14:50 +0100
Re: [PATCH 1/2] cpufreq: schedutil: Fix per-CPU structure initialization in sugov_start() Viresh Kumar <viresh.kumar@linaro.org> - 2017-03-20 04:30 +0100
Re: [PATCH 1/2] cpufreq: schedutil: Fix per-CPU structure initialization in sugov_start() "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 13:50 +0100
[RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-19 14:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-19 22:40 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-19 22:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-20 12:10 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 13:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Viresh Kumar <viresh.kumar@linaro.org> - 2017-03-20 05:00 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-20 09:30 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-20 13:40 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Joel Fernandes <joelaf@google.com> - 2017-03-23 01:00 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-23 23:10 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Joel Fernandes <joelaf@google.com> - 2017-03-25 04:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-27 09:10 +0200
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 14:10 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-20 14:40 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 14:30 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-20 12:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 13:50 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-20 14:00 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-20 14:10 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 14:40 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-20 15:20 +0100
Re: [RFC][PATCH 2/2] cpufreq: schedutil: Force max frequency on busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 14:20 +0100
[RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-20 23:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Viresh Kumar <viresh.kumar@linaro.org> - 2017-03-21 07:50 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-21 13:40 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-21 10:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 13:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 14:30 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-21 14:40 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-21 15:30 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-21 15:40 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 15:50 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-21 16:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 16:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-21 16:30 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 18:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-21 18:30 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 16:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 16:20 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 20:30 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-21 16:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 16:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 15:40 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 16:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Peter Zijlstra <peterz@infradead.org> - 2017-03-21 16:00 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-21 18:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-21 18:10 +0100
Re: [RFC][PATCH v2 2/2] cpufreq: schedutil: Avoid decreasing frequency of busy CPUs Patrick Bellasi <patrick.bellasi@arm.com> - 2017-03-21 13:00 +0100
[RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-03-22 00:20 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Peter Zijlstra <peterz@infradead.org> - 2017-03-22 10:30 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Viresh Kumar <viresh.kumar@linaro.org> - 2017-03-22 11:10 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Joel Fernandes <joelaf@google.com> - 2017-03-23 02:10 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Sai Gurrappadi <sgurrappadi@nvidia.com> - 2017-03-23 20:30 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Sai Gurrappadi <sgurrappadi@nvidia.com> - 2017-03-23 22:00 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-24 02:40 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Sai Gurrappadi <sgurrappadi@nvidia.com> - 2017-03-24 20:20 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Sai Gurrappadi <sgurrappadi@nvidia.com> - 2017-03-25 02:20 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-25 02:40 +0100
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Vincent Guittot <vincent.guittot@linaro.org> - 2017-03-27 09:20 +0200
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely Sai Gurrappadi <sgurrappadi@nvidia.com> - 2017-03-27 23:10 +0200
Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely "Rafael J. Wysocki" <rafael@kernel.org> - 2017-03-27 23:20 +0200
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Sai Gurrappadi <sgurrappadi@nvidia.com> |
|---|---|
| Date | 2017-03-25 02:20 +0100 |
| Subject | Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely |
| Message-ID | <toIx3-1Ip-1@gated-at.bofh.it> |
| In reply to | #1606069 |
Hi Rafael, On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > The way the schedutil governor uses the PELT metric causes it to > underestimate the CPU utilization in some cases. > > That can be easily demonstrated by running kernel compilation on > a Sandy Bridge Intel processor, running turbostat in parallel with > it and looking at the values written to the MSR_IA32_PERF_CTL > register. Namely, the expected result would be that when all CPUs > were 100% busy, all of them would be requested to run in the maximum > P-state, but observation shows that this clearly isn't the case. > The CPUs run in the maximum P-state for a while and then are > requested to run slower and go back to the maximum P-state after > a while again. That causes the actual frequency of the processor to > visibly oscillate below the sustainable maximum in a jittery fashion > which clearly is not desirable. > > That has been attributed to CPU utilization metric updates on task > migration that cause the total utilization value for the CPU to be > reduced by the utilization of the migrated task. If that happens, > the schedutil governor may see a CPU utilization reduction and will > attempt to reduce the CPU frequency accordingly right away. That > may be premature, though, for example if the system is generally > busy and there are other runnable tasks waiting to be run on that > CPU already. > Thinking out loud a bit, I wonder if what you really want to do is basically: schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, total_cpu_util_avg); Where total_cpu_util_avg tracks the average utilization of the CPU itself over time (% of time the CPU was busy) in the same PELT like manner. The difference here is that it doesn't change instantaneously as tasks migrate in/out but it decays/accumulates just like the per-entity util_avgs. Over time, total_cpu_util_avg and cfs_rq(cpu)->util_avg will tend towards each other the lesser the amount of 'overlap' / overloading. Yes, the above metric would 'overestimate' in case all tasks have migrated away and we are left with an idle CPU. A fix for that could be to just use the PELT value like so: schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, idle_cpu(cpu) ? 0 : total_cpu_util_avg); Note that the problem described here in the commit message doesn't need fully runnable threads, it just needs two threads to execute in parallel on the same CPU for a period of time. I don't think looking at just idle_calls necessarily covers all cases. Thoughts? Thanks, -Sai
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2017-03-25 02:40 +0100 |
| Subject | Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely |
| Message-ID | <toIQp-1P9-3@gated-at.bofh.it> |
| In reply to | #1609054 |
On Sat, Mar 25, 2017 at 2:14 AM, Sai Gurrappadi <sgurrappadi@nvidia.com> wrote: > Hi Rafael, > > On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> The way the schedutil governor uses the PELT metric causes it to >> underestimate the CPU utilization in some cases. >> >> That can be easily demonstrated by running kernel compilation on >> a Sandy Bridge Intel processor, running turbostat in parallel with >> it and looking at the values written to the MSR_IA32_PERF_CTL >> register. Namely, the expected result would be that when all CPUs >> were 100% busy, all of them would be requested to run in the maximum >> P-state, but observation shows that this clearly isn't the case. >> The CPUs run in the maximum P-state for a while and then are >> requested to run slower and go back to the maximum P-state after >> a while again. That causes the actual frequency of the processor to >> visibly oscillate below the sustainable maximum in a jittery fashion >> which clearly is not desirable. >> >> That has been attributed to CPU utilization metric updates on task >> migration that cause the total utilization value for the CPU to be >> reduced by the utilization of the migrated task. If that happens, >> the schedutil governor may see a CPU utilization reduction and will >> attempt to reduce the CPU frequency accordingly right away. That >> may be premature, though, for example if the system is generally >> busy and there are other runnable tasks waiting to be run on that >> CPU already. >> > > Thinking out loud a bit, I wonder if what you really want to do is basically: > > schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, total_cpu_util_avg); > > Where total_cpu_util_avg tracks the average utilization of the CPU itself over time (% of time the CPU was busy) in the same PELT like manner. The difference here is that it doesn't change instantaneously as tasks migrate in/out but it decays/accumulates just like the per-entity util_avgs. > > Over time, total_cpu_util_avg and cfs_rq(cpu)->util_avg will tend towards each other the lesser the amount of 'overlap' / overloading. > > Yes, the above metric would 'overestimate' in case all tasks have migrated away and we are left with an idle CPU. A fix for that could be to just use the PELT value like so: > > schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, idle_cpu(cpu) ? 0 : total_cpu_util_avg); > > Note that the problem described here in the commit message doesn't need fully runnable threads, it just needs two threads to execute in parallel on the same CPU for a period of time. I don't think looking at just idle_calls necessarily covers all cases. > > Thoughts? Well, is the total_cpu_util_avg metric readily available? Thanks, Rafael
[toc] | [prev] | [next] | [standalone]
| From | Vincent Guittot <vincent.guittot@linaro.org> |
|---|---|
| Date | 2017-03-27 09:20 +0200 |
| Subject | Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely |
| Message-ID | <tpx6y-4iG-11@gated-at.bofh.it> |
| In reply to | #1609054 |
On 25 March 2017 at 02:14, Sai Gurrappadi <sgurrappadi@nvidia.com> wrote: > Hi Rafael, > > On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> >> The way the schedutil governor uses the PELT metric causes it to >> underestimate the CPU utilization in some cases. >> >> That can be easily demonstrated by running kernel compilation on >> a Sandy Bridge Intel processor, running turbostat in parallel with >> it and looking at the values written to the MSR_IA32_PERF_CTL >> register. Namely, the expected result would be that when all CPUs >> were 100% busy, all of them would be requested to run in the maximum >> P-state, but observation shows that this clearly isn't the case. >> The CPUs run in the maximum P-state for a while and then are >> requested to run slower and go back to the maximum P-state after >> a while again. That causes the actual frequency of the processor to >> visibly oscillate below the sustainable maximum in a jittery fashion >> which clearly is not desirable. >> >> That has been attributed to CPU utilization metric updates on task >> migration that cause the total utilization value for the CPU to be >> reduced by the utilization of the migrated task. If that happens, >> the schedutil governor may see a CPU utilization reduction and will >> attempt to reduce the CPU frequency accordingly right away. That >> may be premature, though, for example if the system is generally >> busy and there are other runnable tasks waiting to be run on that >> CPU already. >> > > Thinking out loud a bit, I wonder if what you really want to do is basically: > > schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, total_cpu_util_avg); > > Where total_cpu_util_avg tracks the average utilization of the CPU itself over time (% of time the CPU was busy) in the same PELT like manner. The difference here is that it doesn't change instantaneously as tasks migrate in/out but it decays/accumulates just like the per-entity util_avgs. But we loose the interest of immediate decrease when tasks migrate. Instead of total_cpu_util_avg we should better track RT utilization in the same manner so with ongoing work for deadline we will have : total_utilization = cfs.util_avg + rt's util_avg + deadline's util avg and we still take advantage of task migration effect > > Over time, total_cpu_util_avg and cfs_rq(cpu)->util_avg will tend towards each other the lesser the amount of 'overlap' / overloading. > > Yes, the above metric would 'overestimate' in case all tasks have migrated away and we are left with an idle CPU. A fix for that could be to just use the PELT value like so: > > schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, idle_cpu(cpu) ? 0 : total_cpu_util_avg); > > Note that the problem described here in the commit message doesn't need fully runnable threads, it just needs two threads to execute in parallel on the same CPU for a period of time. I don't think looking at just idle_calls necessarily covers all cases. > > Thoughts? > > Thanks, > -Sai
[toc] | [prev] | [next] | [standalone]
| From | Sai Gurrappadi <sgurrappadi@nvidia.com> |
|---|---|
| Date | 2017-03-27 23:10 +0200 |
| Subject | Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely |
| Message-ID | <tpK3M-5Ky-19@gated-at.bofh.it> |
| In reply to | #1609520 |
Hi Vincent, On 03/27/2017 12:04 AM, Vincent Guittot wrote: > On 25 March 2017 at 02:14, Sai Gurrappadi <sgurrappadi@nvidia.com> wrote: >> Hi Rafael, >> >> On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>> >>> The way the schedutil governor uses the PELT metric causes it to >>> underestimate the CPU utilization in some cases. >>> >>> That can be easily demonstrated by running kernel compilation on >>> a Sandy Bridge Intel processor, running turbostat in parallel with >>> it and looking at the values written to the MSR_IA32_PERF_CTL >>> register. Namely, the expected result would be that when all CPUs >>> were 100% busy, all of them would be requested to run in the maximum >>> P-state, but observation shows that this clearly isn't the case. >>> The CPUs run in the maximum P-state for a while and then are >>> requested to run slower and go back to the maximum P-state after >>> a while again. That causes the actual frequency of the processor to >>> visibly oscillate below the sustainable maximum in a jittery fashion >>> which clearly is not desirable. >>> >>> That has been attributed to CPU utilization metric updates on task >>> migration that cause the total utilization value for the CPU to be >>> reduced by the utilization of the migrated task. If that happens, >>> the schedutil governor may see a CPU utilization reduction and will >>> attempt to reduce the CPU frequency accordingly right away. That >>> may be premature, though, for example if the system is generally >>> busy and there are other runnable tasks waiting to be run on that >>> CPU already. >>> >> >> Thinking out loud a bit, I wonder if what you really want to do is basically: >> >> schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, total_cpu_util_avg); >> >> Where total_cpu_util_avg tracks the average utilization of the CPU itself over time (% of time the CPU was busy) in the same PELT like manner. The difference here is that it doesn't change instantaneously as tasks migrate in/out but it decays/accumulates just like the per-entity util_avgs. > > But we loose the interest of immediate decrease when tasks migrate. Indeed, this is not ideal. > Instead of total_cpu_util_avg we should better track RT utilization in > the same manner so with ongoing work for deadline we will have : > total_utilization = cfs.util_avg + rt's util_avg + deadline's util avg > and we still take advantage of task migration effect I agree that we need better tracking for RT and DL tasks but that doesn't solve the overloaded case with more than one CFS thread sharing a CPU. In the overloaded case, we care not just about the instant where the migrate happens but also subsequent windows where the PELT metric is slowly ramping up to reflect the real utilization of a task now that it has a CPU to itself. Maybe there are better ways to solve that though :-) Thanks, -Sai
[toc] | [prev] | [next] | [standalone]
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Date | 2017-03-27 23:20 +0200 |
| Subject | Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely |
| Message-ID | <tpKds-5O4-9@gated-at.bofh.it> |
| In reply to | #1610112 |
On Mon, Mar 27, 2017 at 11:01 PM, Sai Gurrappadi <sgurrappadi@nvidia.com> wrote: > Hi Vincent, > > On 03/27/2017 12:04 AM, Vincent Guittot wrote: >> On 25 March 2017 at 02:14, Sai Gurrappadi <sgurrappadi@nvidia.com> wrote: >>> Hi Rafael, >>> >>> On 03/21/2017 04:08 PM, Rafael J. Wysocki wrote: >>>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>>> >>>> The way the schedutil governor uses the PELT metric causes it to >>>> underestimate the CPU utilization in some cases. >>>> >>>> That can be easily demonstrated by running kernel compilation on >>>> a Sandy Bridge Intel processor, running turbostat in parallel with >>>> it and looking at the values written to the MSR_IA32_PERF_CTL >>>> register. Namely, the expected result would be that when all CPUs >>>> were 100% busy, all of them would be requested to run in the maximum >>>> P-state, but observation shows that this clearly isn't the case. >>>> The CPUs run in the maximum P-state for a while and then are >>>> requested to run slower and go back to the maximum P-state after >>>> a while again. That causes the actual frequency of the processor to >>>> visibly oscillate below the sustainable maximum in a jittery fashion >>>> which clearly is not desirable. >>>> >>>> That has been attributed to CPU utilization metric updates on task >>>> migration that cause the total utilization value for the CPU to be >>>> reduced by the utilization of the migrated task. If that happens, >>>> the schedutil governor may see a CPU utilization reduction and will >>>> attempt to reduce the CPU frequency accordingly right away. That >>>> may be premature, though, for example if the system is generally >>>> busy and there are other runnable tasks waiting to be run on that >>>> CPU already. >>>> >>> >>> Thinking out loud a bit, I wonder if what you really want to do is basically: >>> >>> schedutil_cpu_util(cpu) = max(cpu_rq(cpu)->cfs.util_avg, total_cpu_util_avg); >>> >>> Where total_cpu_util_avg tracks the average utilization of the CPU itself over time (% of time the CPU was busy) in the same PELT like manner. The difference here is that it doesn't change instantaneously as tasks migrate in/out but it decays/accumulates just like the per-entity util_avgs. >> >> But we loose the interest of immediate decrease when tasks migrate. > > Indeed, this is not ideal. > >> Instead of total_cpu_util_avg we should better track RT utilization in >> the same manner so with ongoing work for deadline we will have : >> total_utilization = cfs.util_avg + rt's util_avg + deadline's util avg >> and we still take advantage of task migration effect > > I agree that we need better tracking for RT and DL tasks but that doesn't solve the overloaded case with more than one CFS thread sharing a CPU. > > In the overloaded case, we care not just about the instant where the migrate happens but also subsequent windows where the PELT metric is slowly ramping up to reflect the real utilization of a task now that it has a CPU to itself. > > Maybe there are better ways to solve that though :-) I wonder if it's viable to postpone the utilization update on both the source and target runqueues until the task has been fully migrated? That would make the artificial utilization reductions go away. Thanks, Rafael
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | linux.kernel
csiph-web