From: Quentin Perret <firstname.lastname@example.org> To: "Rafael J. Wysocki" <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework Date: Fri, 10 Aug 2018 10:12:18 +0100 [thread overview] Message-ID: <20180810091216.nieosjtu7l33z4ap@queper01-lin> (raw) In-Reply-To: <2467271.WAtZ4Z8dKT@aspire.rjw.lan> On Friday 10 Aug 2018 at 10:41:56 (+0200), Rafael J. Wysocki wrote: > On Friday, August 10, 2018 10:15:39 AM CEST Quentin Perret wrote: > > On Thursday 09 Aug 2018 at 23:52:29 (+0200), Rafael J. Wysocki wrote: > > > I'm a bit concerned that the code here appears to be designed around the > > > frequency domains concept which seems to be a limitation and which probably > > > is related to the properties of the current generation of hardware. > > > > That's correct. I went for 'frequency domains' only because this is what > > EAS and IPA are interested in, as of today at least. And both of them > > are somewhat dependent on CPU-Freq, which is called CPU-*Freq*, not > > CPU-Perf after all :-) > > Still, cpufreq manages CPU performance scaling really. > > A cpufreq policy may represent a frequency domain or generally a group of > related CPUs and what matters is that there is a coordination between them > and not how that coordination happens at the hardware/firmware level etc. Fair enough :-) > > > > Assumptions like that tend to get tangled into the code tightly over time > > > and they may be hard to untangle from it when new use cases arise later. > > > > > > For example, there probably will be more firmware involvement in future > > > systems and the firmware may not be willing to expose "raw" frequency > > > domains to the OS. That already is the case with P-states on Intel HW and > > > with ACPI CPPC in general. > > > > Agreed, and embedded/mobile systems are going in that direction too ... > > > > > IMO, frequency domains in your current code could be replaced with something > > > more general, like "performance domains" > > > > I don't mind using a more abstract name as long as we keep the same > > assumptions, and especially that all CPUs in a perf. domain *must* have > > the same micro-architecture. > > That's fair enough I think. Good. > > From that assumption result several > > properties that EAS (in its current) form needs. The first one is that > > all CPUs of a performance domain have the same capacity at any possible > > performance state. And the second is that they all consume the same > > amount of (active) power. > > > > I know it is theoretically possible to mix CPU types in the same perf > > domain, but that becomes nightmare-ish to manage in EAS, and I don't > > think there is a single platform like this on the market today. And I > > hope nobody will build one. Peter wanted to mandate that too, I think. > > There are departures, say, at least as far as the capacity is concerned. > > The uarch is the same for all of them, but the max capacity may vary > between them. I assume you're thinking about ITMT and things like that for example ? That's an interesting case indeed, but yes, being able to reach higher freqs for single-threaded workloads shouldn't violate the assumption, I think. > > > providing the scheduler with the (relative) cost of running a task > > > > What do you mean by relative ? That we should normalize the power costs ? > > Or just use an abstract scale, without specifying the unit ? > > I mean "relative with respect to the other choices"; not absolute. > > > The main reason I'm a bit reluctant to do that just now is because IPA > > needs to compare the power of CPUs with the power of other components > > (GPUs, for example). And the power of those other components is specified > > with a specific unit too. So, not imposing a comparable unit for the > > power of CPUs will result in an unspecified behaviour in IPA, and that > > will break things for sure. I would very much like to avoid that, of > > course. > > The absolute power numbers are generally hard to get though. > > In the majority of cases you can figure out what the extra cost of X with > respect to (alternative) Y is (in certain units), but you may not be able > to say what X and Y are equal to in absolute terms (for example, there > may be an unknown component in both X and Y that you cannot measure, but > it may not be relevant for the outcome of the computation). Agreed. EAS and IPA don't care about the absolute real power values, all they care about is relative correctness. But what I really want to avoid is having IPA getting the power of the GPUs in mW, and the power of CPUs in an abstract scale without unit. That _will_ create problems eventually IMO, because the behaviour is undefined. Specifying a unit everywhere is an easy way to enforce a consistent design across sub-systems, that's all. > > What I am currently proposing is to keep the unit (mW) in the EM > > framework so that migrating IPA to using it can be done in a (relatively) > > painless way. On a system where drivers don't know the exact wattage, > > then they should just 'lie' to the EM framework, but it's their job to > > lie coherently to all subsystems and keep things consistent, because all > > subsystems have specified power in comparable units. > > Alternatively, there could be a translation layer between EM and IPA. Hmm, interesting... What do you have in mind exactly ? What would you put in that layer ? > From my experience, if you want people to come up with some numbers, > they will just choose them to game the system this way or another > unless those numbers can be measured directly or are clearly documented. > > And if that happens and then you want to make any significant changes, > you'll need to deal with "regressions" occuring because someone chose > the numbers to make the system behave in a specific way and your changes > break that. > > As a rule, I rather avoid requesting unknown numbers from people. :-) > > > Another solution to solve this problem could be to extend the EM > > framework introduced by this patch and make it manage the EM of any > > device, not just CPUs. Then we could just specify that all power costs > > must be in the same scale, regardless of the actual unit, and register > > the EM of CPUs, GPUs, ... > > However, I was hoping that this patch as-is was enough for a first step, > > and that this extension of the framework could be done in a second step ? > > Thoughts ? > > > > In any case, if we decide to keep the mW unit for now, I should at least > > explain clearly why in the commit message. > > Right. > > Actually, the unit is as good as any other, but you need to bear in mind that > the numbers provided may not be realistic. As long as they're all correct in a relative way, that's fine by me :-) Thanks, Quentin
next prev parent reply other threads:[~2018-08-10 9:12 UTC|newest] Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-07-24 12:25 [PATCH v5 00/14] Energy Aware Scheduling Quentin Perret 2018-07-24 12:25 ` [PATCH v5 01/14] sched: Relocate arch_scale_cpu_capacity Quentin Perret 2018-07-24 12:25 ` [PATCH v5 02/14] sched/cpufreq: Factor out utilization to frequency mapping Quentin Perret 2018-07-24 12:25 ` [PATCH v5 03/14] PM: Introduce an Energy Model management framework Quentin Perret 2018-08-09 21:52 ` Rafael J. Wysocki 2018-08-10 8:15 ` Quentin Perret 2018-08-10 8:41 ` Rafael J. Wysocki 2018-08-10 9:12 ` Quentin Perret [this message] 2018-08-10 11:13 ` Rafael J. Wysocki 2018-08-10 12:30 ` Quentin Perret 2018-08-12 9:49 ` Rafael J. Wysocki 2018-07-24 12:25 ` [PATCH v5 04/14] PM / EM: Expose the Energy Model in sysfs Quentin Perret 2018-07-24 12:25 ` [PATCH v5 05/14] sched/topology: Reference the Energy Model of CPUs when available Quentin Perret 2018-07-24 12:25 ` [PATCH v5 06/14] sched/topology: Lowest energy aware balancing sched_domain level pointer Quentin Perret 2018-07-26 16:00 ` Valentin Schneider 2018-07-26 17:01 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 07/14] sched/topology: Introduce sched_energy_present static key Quentin Perret 2018-07-24 12:25 ` [PATCH v5 08/14] sched/fair: Clean-up update_sg_lb_stats parameters Quentin Perret 2018-07-24 12:25 ` [PATCH v5 09/14] sched: Add over-utilization/tipping point indicator Quentin Perret 2018-08-02 12:26 ` Peter Zijlstra 2018-08-02 13:03 ` Quentin Perret 2018-08-02 13:08 ` Peter Zijlstra 2018-08-02 13:18 ` Quentin Perret 2018-08-02 13:48 ` Vincent Guittot 2018-08-02 14:14 ` Quentin Perret 2018-08-02 15:14 ` Vincent Guittot 2018-08-02 15:30 ` Quentin Perret 2018-08-02 15:55 ` Vincent Guittot 2018-08-02 16:00 ` Quentin Perret 2018-08-02 16:07 ` Vincent Guittot 2018-08-02 16:10 ` Quentin Perret 2018-08-02 16:38 ` Vincent Guittot 2018-08-02 16:59 ` Quentin Perret 2018-08-03 7:48 ` Vincent Guittot 2018-08-03 8:18 ` Quentin Perret 2018-08-03 13:49 ` Vincent Guittot 2018-08-03 14:21 ` Vincent Guittot 2018-08-03 15:55 ` Quentin Perret 2018-08-06 8:40 ` Vincent Guittot 2018-08-06 9:43 ` Quentin Perret 2018-08-06 10:45 ` Vincent Guittot 2018-08-06 11:02 ` Quentin Perret 2018-08-06 10:08 ` Dietmar Eggemann 2018-08-06 10:33 ` Vincent Guittot 2018-08-06 12:29 ` Dietmar Eggemann 2018-08-06 12:37 ` Vincent Guittot 2018-08-06 13:20 ` Dietmar Eggemann 2018-08-09 9:30 ` Vincent Guittot 2018-08-09 9:38 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method Quentin Perret 2018-07-30 19:35 ` skannan 2018-07-31 7:59 ` Quentin Perret 2018-07-31 19:31 ` skannan 2018-08-01 7:32 ` Rafael J. Wysocki 2018-08-01 8:23 ` Quentin Perret 2018-08-01 8:35 ` Rafael J. Wysocki 2018-08-01 9:23 ` Quentin Perret 2018-08-01 9:40 ` Rafael J. Wysocki 2018-08-02 13:04 ` Peter Zijlstra 2018-08-02 15:39 ` Quentin Perret 2018-08-03 13:04 ` Quentin Perret 2018-08-02 12:33 ` Peter Zijlstra 2018-08-02 12:45 ` Peter Zijlstra 2018-08-02 15:21 ` Quentin Perret 2018-08-02 17:36 ` Peter Zijlstra 2018-08-03 12:42 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 11/14] sched/fair: Introduce an energy estimation helper function Quentin Perret 2018-07-24 12:25 ` [PATCH v5 12/14] sched/fair: Select an energy-efficient CPU on task wake-up Quentin Perret 2018-08-02 13:54 ` Peter Zijlstra 2018-08-02 16:21 ` Quentin Perret 2018-07-24 12:25 ` [PATCH v5 13/14] OPTIONAL: arch_topology: Start Energy Aware Scheduling Quentin Perret 2018-07-24 12:25 ` [PATCH v5 14/14] OPTIONAL: cpufreq: dt: Register an Energy Model Quentin Perret
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180810091216.nieosjtu7l33z4ap@queper01-lin \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v5 03/14] PM: Introduce an Energy Model management framework' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).