Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [RFCv7 PATCH 01/10] sched: Compute cpu capacity available at current frequency | Date | Fri, 26 Feb 2016 02:37:19 +0100 |
| |
On Tuesday, February 23, 2016 10:19:16 AM Peter Zijlstra wrote: > On Tue, Feb 23, 2016 at 02:41:20AM +0100, Rafael J. Wysocki wrote: > > > /* > > > + * Returns the current capacity of cpu after applying both > > > + * cpu and freq scaling. > > > + */ > > > +static unsigned long capacity_curr_of(int cpu) > > > +{ > > > + return cpu_rq(cpu)->cpu_capacity_orig * > > > + arch_scale_freq_capacity(NULL, cpu) > > > > What about architectures that don't have this? > > They get the 'default' which is a constant SCHED_CAPACITY_SCALE unit. > > > Why is that an architecture feature? > > Because not all archs can tell the frequency the same way. Some you > program the DVFS state and they really run at this speed, for those you > can simply report back. > > For others, x86 for example, you program a DVFS 'hint' and the hardware > does whatever, we'd have to do APERF/MPERF samples to get an idea of the > actual frequency we ran at. > > Also, the having of this makes the load tracking slightly more > expensive, instead of compile time constants we get function calls and > actual multiplications. Its not _too_ bad, but still.
That's all correct, but my question should rather be: is arch the right granularity?
In theory, there may be ARM64-based platforms using ACPI and behaving like x86 in that respect in the future.
Thanks, Rafael
| |