On 1/16/24 00:53, Ryan Roberts wrote:
On 15/01/2024 21:30, John Hubbard wrote:
On 1/15/24 07:56, Ryan Roberts wrote:
...
-----
When run without options, cgroups v1 or v2 (depending on what is active
on the system) is used in order to get a listing of all user space pids.
That pid list is passed into the core script, as if the user had provided
"--pids pid1 pid2 ...".
-----
Agree with the sentiment; I'll add something similar. Although, I'm no longer
using cgroups to get all the pids - I'm grabbing them from /proc.
--8<--
When run with --pid, the user explicitly specifies the set of pids to scan. e.g.
"--pid 10 [--pid 134 ...]". When run with --cgroup, the user passes either a v1
or v2 cgroup and all pids that belong to the cgroup subtree are scanned. When
run with neither --pid nor --cgroup, the full set of pids on the system is
gathered from /proc and scanned as if the user had provided "--pid 1 --pid 2 ...".
--8<--
Sounds good.
This reminds me that maybe a --pids options is helpful, what do you think?
How about I allow --pid to be specified multiple times? That will make the
parsing easier (and be consistent with the way it works for --cont):
--pid 1 --pid 2 --pid 3 ...
Sure, that works nicely.
thanks,
--
John Hubbard
NVIDIA