https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246940
--- Comment #6 from Conrad Meyer <[email protected]> --- (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. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
