https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246940
--- Comment #7 from t.eichsta...@gmx.net ---
(In reply to Conrad Meyer from comment #6)
Good morning, and thx for your time.
>> [mixed up nice & priority]
> This is a misunderstanding. Nice and priority are orthogonal.
OK I'll try harder to be more precise and choose the right verbs.
>> [my assumption: load values ~ runtime sched classes]
> This is also a misunderstanding; it isn't the categorization used by cp_times.
> [...] That's it.
OK. Got that. Wrong assumption/association.
> I think it would be reasonable to collect and expose the data you want, [...]
I'm glad to hear that. Do you mean to weave in the computations to update a
modern clone of cp_time, with additional fields for the non-traditional (soft)
realtime & user_idle classes, into the "if(usermode)"-branch of statclock()?
And clone the resp. SYSCTL_PROCs for the overall and per-cpu cp_time(s)?
Is it possible to simply add a flag to the existing one and use the very same
function for both sysctl's? Or do we need a wrapper function? These functions
seem to be so simple, I'd resist to copy&paste when all that's different is the
number of fields in an array. Is there an implicit mutex or lock set by one of
these SYSCTL_XXX macros? I have no clue about these SYSCTL things... if you
want do that because it's trivial and useful anyway, I'm happy. If you want to
let me do it instead, because I'm the only one asking for it, I'll dive into it
and come up with a suggestion. Would that need to be against the
FBSD-13_CURRENT src?
> If we want to provide a better laptop experience, it needs to work out of the
> box.
+++ IMHO we can assume laptop users enable powerd or such, and others do not.
> (†): User-driven frequency scaling is kind of a losing game at this point,
> especially with powerd. Idle C-states consume almost nothing regardless of
> frequency.
When any other except the kernel idle task is running, the cpu is in the C0
state, right? So the states >=C1 are not reached as long there's some task
ready to run, because the scheduler picks it up to let it run, right? Thus, to
achieve what I consider ("cool" user_idle tasks), the runtime scheduler had to
provide a mechanism to artificially "retard" an (or all) idle user task, i.e.
give it less time slices (less often), which it currently does not do on an
otherwise idle system. I'm not aware of such a mechanism. The implicit
assumption of the scheduler is to get all work done, optimized and
parameterized for a mix of speed, throughput and (by architecture) "fairness",
and it has no notion neither for ernergy efficiency nor absolute power
consumption. If you suggest the better solution would be to update the
scheduler instead, I'd be interested as well, but probably that's beyond my
current skills. More likely than not. Anyway, it'd be much more complicated
and - foremost - dangerous.
Regarding power consumption, the cpu freq is the dominating factor (in C0
state). That's basic physics. Am I wrong here? Freq scaling based on load
values is what exists and will be in use for the lifetime of today's machines.
If you can point me to what powerd does methodically wrong (other than the
mentioned handling of independant cores), feel free to do so. Likewise, any
other better solution - I welcome your hints.
> Powerd doesn't know how to manage frequency on multiple independent CPUs.
I'll have a look at that. Is this possible on a one-package two-core SMT
system? I have a Core i7-5600U, that's what I can test on bare metal. These
things never interested me more than to survive a test at the univ. Obviously
two virtual SMT cores on one physical core can not have different freqs. The
rest is what I "just use", but if I have to dive into that, I'll do so.
> Intel is moving away from OS-driven p-states entirely; future CPUs will
> simply
> not support it. (Instead, cores can be set to an energy efficiency
> profile on some 0-100 percentage scale.)
Sounds like KISS. It's important to support new hardware, but it's also fair
to support existing hw during it's lifetime. Let's say, two decades.
Sorry for the lengthy mail - I want to have this going (i.e. "cool" user_idle).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
