From owner-freebsd-bugs@freebsd.org Tue Jun 2 19:20:55 2020 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 389BC2F744C for ; Tue, 2 Jun 2020 19:20:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49c22H0q2Lz4YdY for ; Tue, 2 Jun 2020 19:20:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 1BF762F744B; Tue, 2 Jun 2020 19:20:55 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BC262F77E4 for ; Tue, 2 Jun 2020 19:20:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49c22G72M3z4YBL for ; Tue, 2 Jun 2020 19:20:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id ECD22219C3 for ; Tue, 2 Jun 2020 19:20:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 052JKsn4046351 for ; Tue, 2 Jun 2020 19:20:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 052JKssI046349 for bugs@FreeBSD.org; Tue, 2 Jun 2020 19:20:54 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Tue, 02 Jun 2020 19:20:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: Unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: t.eichstaedt@gmx.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 19:20:55 -0000 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.=