[Bug 246940] [wishlist/enhancement, patch incl.]: idle user tasks should be charged as "nice" or "idle" CPU time

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Jun 3 00:27:43 UTC 2020


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246940

--- Comment #6 from Conrad Meyer <cem at freebsd.org> ---
(In reply to t.eichstaedt from comment #4)
> Then what's the idle _user_class_ for?

Scheduler prioritization.

> IMHO one would expect that idle user tasks are implicitely also (at least) nice, same argument: because their scheduling priority is lower than all nice tasks.

This is a misunderstanding.  Nice and priority are orthogonal.

(In reply to t.eichstaedt from comment #5)
> the charge classes supplied by cp_times (roughly) reflect the cpu scheduling classes

This is also a misunderstanding; it isn't the categorization used by cp_times. 
Nice is user threads with nice > 0; user is all other user threads.  Intr is
kernel threads running ithreads.  Idle is kernel threads running idle.  Sys is
all other kernel threads.  That's it.

I think it would be reasonable to collect and expose the data you want, and
have a power manager (useless as they may be)† consume that data instead of
cp_times.  But I don't like changing the historical behavior of cp_times to
charge user CPU as kernel CPU, nor do I like adding yet another sysctl knob for
this behavior.  (Approximately zero users are going to find and enable this
knob.  If we want to provide a better laptop experience, it needs to work out
of the box.)


(†): 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.  Powerd doesn't know how to manage frequency on multiple independent
CPUs.  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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list