On Tue, Dec 15, 2015 at 06:47:20PM +0100, Vincent Guittot wrote: > On 15 December 2015 at 18:15, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Tue, Dec 15, 2015 at 05:59:34PM +0100, Vincent Guittot wrote: > >> On 15 December 2015 at 17:41, Mark Rutland <mark.rutland@xxxxxxx> wrote: > >> > On Tue, Dec 15, 2015 at 04:23:18PM +0000, Catalin Marinas wrote: > >> >> On Tue, Dec 15, 2015 at 03:57:37PM +0000, Mark Rutland wrote: > >> >> > On Tue, Dec 15, 2015 at 03:46:51PM +0000, Juri Lelli wrote: > >> >> > > On 15/12/15 15:32, Mark Rutland wrote: > >> >> > > > On Tue, Dec 15, 2015 at 03:08:13PM +0000, Mark Brown wrote: > >> >> > > > > My expectation is that we just need good enough, not perfect, and that > >> >> > > > > seems to match what Juri is saying about the expectation that most of > >> >> > > > > the fine tuning is done via other knobs. > >> >> > > > > >> >> > > > My expectation is that if a ballpark figure is good enough, it should be > >> >> > > > possible to implement something trivial like bogomips / loop_per_jiffy > >> >> > > > calculation. > >> >> > > > >> >> > > I didn't really followed that, so I might be wrong here, but isn't > >> >> > > already happened a discussion about how we want/like to stop exposing > >> >> > > bogomips info or rely on it for anything but in kernel delay loops? > >> >> > > >> >> > I meant that we could have a benchmark of that level of complexity, > >> >> > rather than those specific values. > >> >> > >> >> Or we could simply let user space use whatever benchmarks or hard-coded > >> >> values it wants and set the capacity via sysfs (during boot). By > >> >> default, the kernel would assume all CPUs equal. > >> > > >> > I assume that a userspace override would be available regardless of > >> > whatever mechanism the kernel uses to determine relative > >> > performance/effinciency. > >> > >> Don't you think that if we let a complete latitude to the userspace > >> to set whatever it wants, it will be used to abuse the kernel (and the > >> scheduler in particular ) and that this will finish in a real mess to > >> understand what is wrong when a task is not placed where it should be. > > > > I'm not sure I follow what you mean by "abuse" here. Userspace currently > > can force the scheduler to make sub-optimal decisions in a number of > > ways, e.g. > > > > * Hot-unplugging the preferred CPUs > > * Changing a task's affinity mask > > * Setting the nice value of a task > > * Using rlimits and/or cgroups > > * Using a cpufreq governor > > * Fork-bombing > > All these are parameters have a meaning (except the last one). By > abusing i mean setting the capacity of the most powerful cpu to 1 for > no good reason except to abuse the scheduler so the latter will not > put that much tasks on it just because the current running use case > is more efficient if the big core is not used. Surely it's better to allow them to "abuse" the kernel in that manner than to place otherwise insane values into a DT? Especially if they can later change to a sane value? For that particular case it's easy to hotplug out the big core, or to set the affinity of tasks to avoid it. Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
