linux-kernel - Re: [PATCH v3 0/2] Exposing nice CPU usage to userspace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <qjbbaywlodoojlb5n3vavgck2jrffofnlzpf7pc5h7fsyu5y7o@oqh5vbuns7ve>
Date: Thu, 26 Sep 2024 20:10:35 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Joshua Hahn <joshua.hahnjy@...il.com>
Cc: tj@...nel.org, cgroups@...r.kernel.org, hannes@...xchg.org, 
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, lizefan.x@...edance.com, 
	shuah@...nel.org
Subject: Re: [PATCH v3 0/2] Exposing nice CPU usage to userspace

On Mon, Sep 23, 2024 at 07:20:04AM GMT, Joshua Hahn <joshua.hahnjy@...il.com> wrote:
> From: Joshua Hahn <joshua.hahn6@...il.com>
> 
> v2 -> v3: Signed-off-by & renamed subject for clarity.
> v1 -> v2: Edited commit messages for clarity.

Thanks for the version changelog, appreciated!

...
> Exposing this metric will allow users to accurately probe the niced CPU
> metric for each workload, and make more informed decisions when
> directing higher priority tasks.

Possibly an example of how this value (combined with some other?) is
used for decisions could shed some light on this and justify adding this
attribute.

Thanks,
Michal

(I'll respond here to Tejun's message from v2 thread.)

On Tue, Sep 10, 2024 at 11:01:07AM GMT, Tejun Heo <tj@...nel.org> wrote:
> I think it's as useful as system-wide nice metric is.

Exactly -- and I don't understand how that system-wide value (without
any cgroups) is useful.
If I don't know how many there are niced and non-niced tasks and what
their runnable patterns are, the aggregated nice time can have ambiguous
interpretations.

> I think there are benefits to mirroring system wide metrics, at least
> ones as widely spread as nice.

I agree with benefits of mirroring of some system wide metrics when they
are useful <del>but not all of them because it's difficult/impossible to take
them away once they're exposed</del>. Actually, readers _should_ handle
missing keys gracefuly, so this may be just fine.

(Is this nice time widely spread? (I remember the field from `top`, still
not sure how to use it.) Are other proc_stat(5) fields different?

I see how this can be the global analog on leaf cgroups but
interpretting middle cgroups with children of different cpu.weights?)

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)