Date: Wed, 03 Jun 2020 00:27:39 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 246940] [wishlist/enhancement, patch incl.]: idle user tasks should be charged as "nice" or "idle" CPU time Message-ID: <bug-246940-227-HlB0XjkeSj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-246940-227@https.bugs.freebsd.org/bugzilla/> References: <bug-246940-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D246940 --- Comment #6 from Conrad Meyer <cem@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 schedul= ing classes This is also a misunderstanding; it isn't the categorization used by cp_tim= es.=20 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)=E2=80=A0 consume that data in= stead 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 o= ut of the box.) (=E2=80=A0): 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 indepen= dent CPUs. Intel is moving away from OS-driven p-states entirely; future CPUs w= ill simply not support it. (Instead, cores can be set to an energy efficiency profile on some 0-100 percentage scale.) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-246940-227-HlB0XjkeSj>