Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1649503
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection |
| Date | 2017-05-24 13:40 +0200 |
| Message-ID | <tKCNX-1KT-5@gated-at.bofh.it> (permalink) |
| References | <tKdPz-N6-5@gated-at.bofh.it> <tKoL1-8pv-45@gated-at.bofh.it> <tKAMa-tv-15@gated-at.bofh.it> <tKB5w-AM-11@gated-at.bofh.it> <tKBfd-EZ-37@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, May 24, 2017 at 10:50:53AM +0100, Juri Lelli wrote: > Agreed. However, problem seems to be that > > - in my opinion (current implementation) this translated into scaling > runtime considering current freq and cpu-max-capacity; and this is > required when frequency scaling is enabled and we still want to meet > a task's guaranteed bandwidth Just so. The bandwidth they request is based on instructions/work. We need to get a certain amount of instructions sorted. Nobody cares we get an exact 10% at random frequency if they loose they finger because we didn't get that final instruction out that stops the saw blade. > - Luca seemed instead to be inclined to say that, if we scale runtime > for !reclaim tasks, such tasks are basically allowed to run for more > time (when frequency is lower than max) by using some of the > bandwidth not allocated to themselves Yes, that's a wrong view :-) We don't care about 'time', we care about getting the instruction stream / work completed.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
[PATCH RFC 1/8] sched/cpufreq_schedutil: make use of DEADLINE utilization signal Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
[PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-05-23 11:00 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Peter Zijlstra <peterz@infradead.org> - 2017-05-23 21:10 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:10 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Peter Zijlstra <peterz@infradead.org> - 2017-05-23 21:40 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2017-05-24 01:40 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Peter Zijlstra <peterz@infradead.org> - 2017-05-24 09:10 +0200
Re: [PATCH RFC 4/8] sched/cpufreq_schedutil: split utilization signals Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:10 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra <peterz@infradead.org> - 2017-05-23 22:40 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 00:00 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-05-24 11:30 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 11:50 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Juri Lelli <juri.lelli@arm.com> - 2017-05-24 12:00 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 13:40 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Luca Abeni <luca.abeni@santannapisa.it> - 2017-05-24 12:10 +0200
Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection Peter Zijlstra <peterz@infradead.org> - 2017-05-24 13:40 +0200
csiph-web