Date: Tue, 02 Jun 2020 19:20:44 +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 "user" CPU time Message-ID: <bug-246940-227-rp3MsgxpY3@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 #4 from t.eichstaedt@gmx.net --- > Why is it counter-intuitive that user processes are counted in user CPU t= ime? When they are neither "nice" nor "idle", it's not. But when they are in the idle class, IMHO a mortal user would expect them n= ot to be charged as user CPU time, since their scheduling priority is even low= er than all nice tasks. > "Idle" is for kernel idle threads, nothing else. Then what's the idle _user_class_ for? > Low-priority user programs can be charged as "nice" So this means I have to apply both "nice" and "idprio". OK, but IMHO one w= ould expect that idle user tasks are implicitely also (at least) nice, same argument: because their scheduling priority is lower than all nice tasks. I totally agree to a bit of resistance to introduce new sysctl's and in general, accepting patches, no matter how trivial they are. In this case, however, I'd kindly suggest the issue that currently, idle us= er tasks do affect the CPU freq scaling (becasause they are charged as "user" time) and with this patch, have an effect that I (and presumably many other= s) consider useful, i.e. one can run tasks as idle and know that they do not affect the CPU freq scaling - like the idle kernel task(s). This is at least useful for mobile devices running AC-offline (or solar-powered). It's useful for desktops, one can switch between fullpower(noisy) and quite mode for background tasks. It can be even useful for servers to do such a switch on power-outage. The patch is non-intrusive, since the default is to retain the current behaviour. --=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-rp3MsgxpY3>