This is an idea for substantially reducing the number of syscalls needed
by monitoring tools whilst mostly re-using the existing API.
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
A stat line for each process in the existing format.
* /proc/all/statm
statm lines but starting with a PID column.
* /proc/all/status
status info for all processes in the existing format.
* /proc/all/io
The existing /proc/pid/io data but formatted as a single line for
each process, similarly to stat/statm, with a PID column added.
* /proc/all/statx
Gathers info from stat, statm and io; the purpose is actually
not so much to reduce syscalls but to help userspace be more
efficient by not having to store data in e.g. hashtables in order
to gather it from separate /proc/all/ files.
The format proposed here starts with the unchanged stat line
and begins the other info with a few characters, repeating for
each process:
...
25 (cat) R 1 1 0 0 -1 4194304 185 0 16 0 2 0 0 0 20 ...
m 662 188 167 5 0 112 0
io 4292 0 12 0 0 0 0
...
There has been a proposal with some overlapping goals: /proc/task-diag
(https://github.com/avagin/linux-task-diag), but I'm not sure about
its current status.
Best Wishes,
Eugene
Eugene Lubarsky (5):
fs/proc: Introduce /proc/all/stat
fs/proc: Introduce /proc/all/statm
fs/proc: Introduce /proc/all/status
fs/proc: Introduce /proc/all/io
fs/proc: Introduce /proc/all/statx
fs/proc/base.c | 215 +++++++++++++++++++++++++++++++++++++++++++--
fs/proc/internal.h | 1 +
fs/proc/root.c | 1 +
3 files changed, 210 insertions(+), 7 deletions(-)
--
2.25.1
Returns stat lines for all visible processes in the existing format,
aiming to substantially reduce the number of syscalls that are needed
for this common task.
Signed-off-by: Eugene Lubarsky <redacted>
---
fs/proc/base.c | 98 ++++++++++++++++++++++++++++++++++++++++++++++
fs/proc/internal.h | 1 +
fs/proc/root.c | 1 +
3 files changed, 100 insertions(+)
Returns status lines for all visible processes in the existing format.
Signed-off-by: Eugene Lubarsky <redacted>
---
fs/proc/base.c | 10 ++++++++++
1 file changed, 10 insertions(+)
Gathers info from stat, statm and io files.
The purpose is not so much to reduce syscall numbers but to help
userspace not have to store data in e.g. hashtables in order to
gather it from separate /proc/all files.
The format starts with an unchanged stat line and begins the
statm & io lines with "m" or "io", repeating these for each process.
e.g.
...
25 (cat) R 1 1 0 0 -1 4194304 185 0 16 0 2 0 0 0 20 ...
m 662 188 167 5 0 112 0
io 4292 0 12 0 0 0 0
...
Signed-off-by: Eugene Lubarsky <redacted>
---
fs/proc/base.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
Returns io info for all visible processes.
The data is the same as /proc/[pid]/io but formatted as a series
of numbers on a single line. A PID column is also prepended.
Signed-off-by: Eugene Lubarsky <redacted>
---
fs/proc/base.c | 66 ++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 59 insertions(+), 7 deletions(-)
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
I think the problem will be defining "all" in the case of the specific
namespace you are dealing with, right? How will this handle all of
those issues properly for all of these different statisics?
thanks,
greg k-h
The proposed readfile sounds great and would help, but if there are
1000 processes wouldn't that require 1000 readfile calls to read their
proc files?
With something like this the stats for 1000 processes could be
retrieved with an open, a few reads and a close.
quoted
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
I think the problem will be defining "all" in the case of the specific
namespace you are dealing with, right? How will this handle all of
those issues properly for all of these different statisics?
Currently I'm trying to re-use the existing code in fs/proc that
controls which PIDs are visible, but may well be missing something..
Best Wishes,
Eugene
The proposed readfile sounds great and would help, but if there are
1000 processes wouldn't that require 1000 readfile calls to read their
proc files?
Yes, but that should be better than 1000 open, 1000 read, and then 1000
close calls, right? :)
With something like this the stats for 1000 processes could be
retrieved with an open, a few reads and a close.
And have you benchmarked any of this? Try working with the common tools
that want this information and see if it actually is noticeable (hint, I
have been doing that with the readfile work and it's surprising what the
results are in places...)
quoted
quoted
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
I think the problem will be defining "all" in the case of the specific
namespace you are dealing with, right? How will this handle all of
those issues properly for all of these different statisics?
Currently I'm trying to re-use the existing code in fs/proc that
controls which PIDs are visible, but may well be missing something..
Try it out and see if it works correctly. And pid namespaces are not
the only thing these days from what I call :)
thanks,
greg k-h
From: Andrei Vagin <hidden> Date: 2020-08-12 07:51:42
On Tue, Aug 11, 2020 at 12:58:47AM +1000, Eugene Lubarsky wrote:
This is an idea for substantially reducing the number of syscalls needed
by monitoring tools whilst mostly re-using the existing API.
The proposed files in this proof-of-concept patch set are:
* /proc/all/stat
A stat line for each process in the existing format.
* /proc/all/statm
statm lines but starting with a PID column.
* /proc/all/status
status info for all processes in the existing format.
* /proc/all/io
The existing /proc/pid/io data but formatted as a single line for
each process, similarly to stat/statm, with a PID column added.
* /proc/all/statx
Gathers info from stat, statm and io; the purpose is actually
not so much to reduce syscalls but to help userspace be more
efficient by not having to store data in e.g. hashtables in order
to gather it from separate /proc/all/ files.
The format proposed here starts with the unchanged stat line
and begins the other info with a few characters, repeating for
each process:
...
25 (cat) R 1 1 0 0 -1 4194304 185 0 16 0 2 0 0 0 20 ...
m 662 188 167 5 0 112 0
io 4292 0 12 0 0 0 0
...
There has been a proposal with some overlapping goals: /proc/task-diag
(https://github.com/avagin/linux-task-diag), but I'm not sure about
its current status.
I rebased the task_diag patches on top of v5.8:
https://github.com/avagin/linux-task-diag/tree/v5.8-task-diag
/proc/pid files have three major limitations:
* Requires at least three syscalls per process per file
open(), read(), close()
* Variety of formats, mostly text based
The kernel spent time to encode binary data into a text format and
then tools like top and ps spent time to decode them back to a binary
format.
* Sometimes slow due to extra attributes
For example, /proc/PID/smaps contains a lot of useful informations
about memory mappings and memory consumption for each of them. But
even if we don't need memory consumption fields, the kernel will
spend time to collect this information.
More details and numbers are in this article:
https://avagin.github.io/how-fast-is-procfs
This new interface doesn't have only one of these limitations, but
task_diag doesn't have all of them.
And I compared how fast each of these interfaces:
The test environment:
CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
RAM: 16GB
kernel: v5.8 with task_diag and /proc/all patches.
100K processes:
$ ps ax | wc -l
10228
$ time cat /proc/all/status > /dev/null
real 0m0.577s
user 0m0.017s
sys 0m0.559s
task_proc_all is used to read /proc/pid/status for all tasks:
https://github.com/avagin/linux-task-diag/blob/master/tools/testing/selftests/task_diag/task_proc_all.c
$ time ./task_proc_all status
tasks: 100230
real 0m0.924s
user 0m0.054s
sys 0m0.858s
/proc/all/status is about 40% faster than /proc/*/status.
Now let's take a look at the perf output:
$ time perf record -g cat /proc/all/status > /dev/null
$ perf report
- 98.08% 1.38% cat [kernel.vmlinux] [k] entry_SYSCALL_64
- 96.70% entry_SYSCALL_64
- do_syscall_64
- 94.97% ksys_read
- 94.80% vfs_read
- 94.58% proc_reg_read
- seq_read
- 87.95% proc_pid_status
+ 13.10% seq_put_decimal_ull_width
- 11.69% task_mem
+ 9.48% seq_put_decimal_ull_width
+ 10.63% seq_printf
- 10.35% cpuset_task_status_allowed
+ seq_printf
- 9.84% render_sigset_t
1.61% seq_putc
+ 1.61% seq_puts
+ 4.99% proc_task_name
+ 4.11% seq_puts
- 3.76% render_cap_t
2.38% seq_put_hex_ll
+ 1.25% seq_puts
2.64% __task_pid_nr_ns
+ 1.54% get_task_mm
+ 1.34% __lock_task_sighand
+ 0.70% from_kuid_munged
0.61% get_task_cred
0.56% seq_putc
0.52% hugetlb_report_usage
0.52% from_kgid_munged
+ 4.30% proc_all_next
+ 0.82% _copy_to_user
We can see that the kernel spent more than 50% of the time to encode binary
data into a text format.
Now let's see how fast task_diag:
$ time ./task_diag_all all -c -q
real 0m0.087s
user 0m0.001s
sys 0m0.082s
Maybe we need resurrect the task_diag series instead of inventing
another less-effective interface...
Thanks,
Andrei
/proc/pid files have three major limitations:
* Requires at least three syscalls per process per file
open(), read(), close()
* Variety of formats, mostly text based
The kernel spent time to encode binary data into a text format and
then tools like top and ps spent time to decode them back to a binary
format.
* Sometimes slow due to extra attributes
For example, /proc/PID/smaps contains a lot of useful informations
about memory mappings and memory consumption for each of them. But
even if we don't need memory consumption fields, the kernel will
spend time to collect this information.
that's what I recall as well.
More details and numbers are in this article:
https://avagin.github.io/how-fast-is-procfs
This new interface doesn't have only one of these limitations, but
task_diag doesn't have all of them.
And I compared how fast each of these interfaces:
The test environment:
CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
RAM: 16GB
kernel: v5.8 with task_diag and /proc/all patches.
100K processes:
$ ps ax | wc -l
10228
100k processes but showing 10k here??
$ time cat /proc/all/status > /dev/null
real 0m0.577s
user 0m0.017s
sys 0m0.559s
task_proc_all is used to read /proc/pid/status for all tasks:
https://github.com/avagin/linux-task-diag/blob/master/tools/testing/selftests/task_diag/task_proc_all.c
$ time ./task_proc_all status
tasks: 100230
real 0m0.924s
user 0m0.054s
sys 0m0.858s
/proc/all/status is about 40% faster than /proc/*/status.
Now let's take a look at the perf output:
$ time perf record -g cat /proc/all/status > /dev/null
$ perf report
- 98.08% 1.38% cat [kernel.vmlinux] [k] entry_SYSCALL_64
- 96.70% entry_SYSCALL_64
- do_syscall_64
- 94.97% ksys_read
- 94.80% vfs_read
- 94.58% proc_reg_read
- seq_read
- 87.95% proc_pid_status
+ 13.10% seq_put_decimal_ull_width
- 11.69% task_mem
+ 9.48% seq_put_decimal_ull_width
+ 10.63% seq_printf
- 10.35% cpuset_task_status_allowed
+ seq_printf
- 9.84% render_sigset_t
1.61% seq_putc
+ 1.61% seq_puts
+ 4.99% proc_task_name
+ 4.11% seq_puts
- 3.76% render_cap_t
2.38% seq_put_hex_ll
+ 1.25% seq_puts
2.64% __task_pid_nr_ns
+ 1.54% get_task_mm
+ 1.34% __lock_task_sighand
+ 0.70% from_kuid_munged
0.61% get_task_cred
0.56% seq_putc
0.52% hugetlb_report_usage
0.52% from_kgid_munged
+ 4.30% proc_all_next
+ 0.82% _copy_to_user
We can see that the kernel spent more than 50% of the time to encode binary
data into a text format.
Now let's see how fast task_diag:
$ time ./task_diag_all all -c -q
real 0m0.087s
user 0m0.001s
sys 0m0.082s
Maybe we need resurrect the task_diag series instead of inventing
another less-effective interface...
I think the netlink message design is the better way to go. As system
sizes continue to increase (> 100 cpus is common now) you need to be
able to pass the right data to userspace as fast as possible to keep up
with what can be a very dynamic userspace and set of processes.
When you first proposed this idea I was working on systems with >= 1k
cpus and the netlink option was able to keep up with a 'make -j N' on
those systems. `perf record` walking /proc would never finish
initializing - I had to add a "done initializing" message to know when
to start a test. With the task_diag approach, perf could collect the
data in short order and move on to recording data.
/proc/pid files have three major limitations:
* Requires at least three syscalls per process per file
open(), read(), close()
* Variety of formats, mostly text based
The kernel spent time to encode binary data into a text format and
then tools like top and ps spent time to decode them back to a binary
format.
* Sometimes slow due to extra attributes
For example, /proc/PID/smaps contains a lot of useful informations
about memory mappings and memory consumption for each of them. But
even if we don't need memory consumption fields, the kernel will
spend time to collect this information.
that's what I recall as well.
quoted
More details and numbers are in this article:
https://avagin.github.io/how-fast-is-procfs
This new interface doesn't have only one of these limitations, but
task_diag doesn't have all of them.
And I compared how fast each of these interfaces:
The test environment:
CPU: Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz
RAM: 16GB
kernel: v5.8 with task_diag and /proc/all patches.
100K processes:
$ ps ax | wc -l
10228
100k processes but showing 10k here??
I'm sure that one zero has been escaped from here. task_proc_all shows
a number of tasks too and it shows 100230.
On Wed, 12 Aug 2020 00:51:35 -0700
Andrei Vagin [off-list ref] wrote:
Maybe we need resurrect the task_diag series instead of inventing
another less-effective interface...
I would certainly welcome the resurrection of task_diag - it is clearly
more efficient than this /proc/all/ idea. It would be good to find out
if there's anything in particular that's currently blocking it.
This RFC is mainly meant to check whether such an addition would
be acceptable from an API point of view. It currently has an obvious
performance issue in that seq_file seems to only return one page at a
time so lots of read syscalls are still required. However I may not
have the time to figure out a proposed fix for this by myself.
Regardless, text-based formats can't match the efficiency of task_diag,
but binary ones are also possible.
Best Wishes,
Eugene
From: Andrei Vagin <hidden> Date: 2020-08-20 17:42:30
On Fri, Aug 14, 2020 at 01:01:00AM +1000, Eugene Lubarsky wrote:
On Wed, 12 Aug 2020 00:51:35 -0700
Andrei Vagin [off-list ref] wrote:
quoted
Maybe we need resurrect the task_diag series instead of inventing
another less-effective interface...
I would certainly welcome the resurrection of task_diag - it is clearly
more efficient than this /proc/all/ idea. It would be good to find out
if there's anything in particular that's currently blocking it.
Unfotunatly, I don't have enough time to lead a process of pushing
task_diag into the upstream. So if it is interesting for you, you can
restart this process and I am ready to help as much as time will permit.
I think the main blocking issue was a lack of interest from the wide
audience to this. The slow proc is the problem just for a few users, but
task_diag is a big subsystem that repeats functionality of another
subsystem with all derived problems like code duplication.
Another blocking issue is a new interface. There was no consensus on
this. Initially, I suggested to use netlink sockets, but developers from
non-network subsystem objected on this, so the transaction file
interface was introduced. The main idea similar to netlink sockets is
that we write a request and read a response.
There were some security concerns but I think I fixed them.
This RFC is mainly meant to check whether such an addition would
be acceptable from an API point of view. It currently has an obvious
performance issue in that seq_file seems to only return one page at a
time so lots of read syscalls are still required. However I may not
have the time to figure out a proposed fix for this by myself.
Regardless, text-based formats can't match the efficiency of task_diag,
but binary ones are also possible.
I don't have objections to this series. It can be an option if we
will decide that we don't want to do a major rework here.
Thanks,
Andrei
On Mon, 10 Aug 2020 17:41:32 +0200
Greg KH [off-list ref] wrote:
On Tue, Aug 11, 2020 at 01:27:00AM +1000, Eugene Lubarsky wrote:
quoted
On Mon, 10 Aug 2020 17:04:53 +0200
Greg KH [off-list ref] wrote:
And have you benchmarked any of this? Try working with the common
tools that want this information and see if it actually is noticeable
(hint, I have been doing that with the readfile work and it's
surprising what the results are in places...)
Apologies for the delay. Here are some benchmarks with atop.
Patch to atop at: https://github.com/eug48/atop/commits/proc-all
Patch to add /proc/all/schedstat & cpuset below.
atop not collecting threads & cmdline as /proc/all/ doesn't support it.
10,000 processes, kernel 5.8, nested KVM, 2 cores of i7-6700HQ @ 2.60GHz
# USE_PROC_ALL=0 ./atop -w test 1 &
# pidstat -p $(pidof atop) 1
01:33:05 %usr %system %guest %wait %CPU CPU Command
01:33:06 33.66 33.66 0.00 0.99 67.33 1 atop
01:33:07 33.00 32.00 0.00 2.00 65.00 0 atop
01:33:08 34.00 31.00 0.00 1.00 65.00 0 atop
...
Average: 33.15 32.79 0.00 1.09 65.94 - atop
# USE_PROC_ALL=1 ./atop -w test 1 &
# pidstat -p $(pidof atop) 1
01:33:33 %usr %system %guest %wait %CPU CPU Command
01:33:34 28.00 14.00 0.00 1.00 42.00 1 atop
01:33:35 28.00 14.00 0.00 0.00 42.00 1 atop
01:33:36 26.00 13.00 0.00 0.00 39.00 1 atop
...
Average: 27.08 12.86 0.00 0.35 39.94 - atop
So CPU usage goes down from ~65% to ~40%.
Data collection times in milliseconds are:
# xsv cat columns proc.csv procall.csv \
field min max mean stddev
/proc time 558 625 586.59 18.29
/proc/all time 231 262 243.56 8.02
Much performance optimisation can still be done, e.g. the modified atop
uses fgets which is reading 1KB at a time, and seq_file seems to only
return 4KB pages. task_diag should be much faster still.
I'd imagine this sort of thing would be useful for daemons monitoring
large numbers of processes. I don't run such systems myself; my initial
motivation was frustration with the Kubernetes kubelet having ~2-4% CPU
usage even with a couple of containers. Basic profiling suggests syscalls
have a lot to do with it - it's actually reading loads of tiny cgroup files
and enumerating many directories every 10 seconds, but /proc has similar
issues and seemed easier to start with.
Anyway, I've read that io_uring could also help here in the near future,
which would be really cool especially if there was a way to enumerate
directories and read many files regex-style in a single operation,
e.g. /proc/[0-9].*/(stat|statm|io)
quoted
Currently I'm trying to re-use the existing code in fs/proc that
controls which PIDs are visible, but may well be missing
something..
Try it out and see if it works correctly. And pid namespaces are not
the only thing these days from what I call :)
I've tried `unshare --fork --pid --mount-proc cat /proc/all/stat`
which seems to behave correctly. ptrace flags are handled by the
existing code.
Best Wishes,
Eugene
From 2ffc2e388f7ce4e3f182c2442823e5f13bae03dd Mon Sep 17 00:00:00 2001
From: Eugene Lubarsky <redacted>
Date: Tue, 25 Aug 2020 12:36:41 +1000
Subject: [RFC PATCH] fs/proc: /proc/all: add schedstat and cpuset
Signed-off-by: Eugene Lubarsky <redacted>
---
fs/proc/base.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
On Thu, 20 Aug 2020 10:41:39 -0700
Andrei Vagin [off-list ref] wrote:
Unfotunatly, I don't have enough time to lead a process of pushing
task_diag into the upstream. So if it is interesting for you, you can
restart this process and I am ready to help as much as time will
permit.
I think the main blocking issue was a lack of interest from the wide
audience to this. The slow proc is the problem just for a few users,
but task_diag is a big subsystem that repeats functionality of another
subsystem with all derived problems like code duplication.
Unfortunately I don't have much time either and yes it sounds like
upstreaming a new interface like this will require input & enthusiasm
from more of those who are monitoring large numbers of processes,
which is not really me..
A related issue is that task_diag doesn't currently support the cgroup
filesystem which has the same issues as /proc and is accessed very
heavily by e.g. the Kubernetes kubelet cadvisor. Perhaps more interest
in tackling this could come from the Kubernetes community.
Another blocking issue is a new interface. There was no consensus on
this. Initially, I suggested to use netlink sockets, but developers
from non-network subsystem objected on this, so the transaction file
interface was introduced. The main idea similar to netlink sockets is
that we write a request and read a response.
There were some security concerns but I think I fixed them.
There's currently a lot of momentum behind io_uring which could not only
enable efficient enumeration and retrieval of small files but maybe it
would also be a more natural place for an API like task_diag..
Best Wishes,
Eugene