From: Ivan Babrou <ivan@cloudflare.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@cloudflare.com,
Ivan Babrou <ivan@cloudflare.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kalesh Singh <kaleshsingh@google.com>
Subject: [RFC] proc: report open files as size in stat() for /proc/pid/fd
Date: Fri, 16 Sep 2022 16:08:52 -0700 [thread overview]
Message-ID: <20220916230853.49056-1-ivan@cloudflare.com> (raw)
Many monitoring tools include open file count as a metric. Currently
the only way to get this number is to enumerate the files in /proc/pid/fd.
The problem with the current approach is that it does many things people
generally don't care about when they need one number for a metric.
In our tests for cadvisor, which reports open file counts per cgroup,
we observed that reading the number of open files is slow. Out of 35.23%
of CPU time spent in `proc_readfd_common`, we see 29.43% spent in
`proc_fill_cache`, which is responsible for filling dentry info.
Some of this extra time is spinlock contention, but it's a contention
for the lock we don't want to take to begin with.
We considered putting the number of open files in /proc/pid/stat.
Unfortunately, counting the number of fds involves iterating the fdtable,
which means that it might slow down /proc/pid/stat for processes
with many open files. Instead we opted to put this info in /proc/pid/fd
as a size member of the stat syscall result. Previously the reported
number was zero, so there's very little risk of breaking anything,
while still providing a somewhat logical way to count the open files.
Previously:
```
$ sudo stat /proc/1/fd | head -n2
File: /proc/1/fd
Size: 0 Blocks: 0 IO Block: 1024 directory
```
With this patch:
```
$ sudo stat /proc/1/fd | head -n2
File: /proc/1/fd
Size: 65 Blocks: 0 IO Block: 1024 directory
```
Correctness check:
```
$ sudo ls /proc/1/fd | wc -l
65
```
There are two alternatives to this approach that I can see:
* Expose /proc/pid/fd_count with a count there
* Make fd count acces O(1) and expose it in /proc/pid/status
I can probably figure out how to do the former, but the latter
will require somebody with more experience in file code than myself.
Signed-off-by: Ivan Babrou <ivan@cloudflare.com>
---
fs/proc/fd.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/fs/proc/fd.c b/fs/proc/fd.c
index 913bef0d2a36..c7ac142500a8 100644
--- a/fs/proc/fd.c
+++ b/fs/proc/fd.c
@@ -279,6 +279,29 @@ static int proc_readfd_common(struct file *file, struct dir_context *ctx,
return 0;
}
+static int proc_readfd_count(struct inode *inode)
+{
+ struct task_struct *p = get_proc_task(inode);
+ unsigned int fd = 0, count = 0;
+
+ if (!p)
+ return -ENOENT;
+
+ rcu_read_lock();
+ while (task_lookup_next_fd_rcu(p, &fd)) {
+ rcu_read_unlock();
+
+ count++;
+ fd++;
+
+ cond_resched();
+ rcu_read_lock();
+ }
+ rcu_read_unlock();
+ put_task_struct(p);
+ return count;
+}
+
static int proc_readfd(struct file *file, struct dir_context *ctx)
{
return proc_readfd_common(file, ctx, proc_fd_instantiate);
@@ -319,9 +342,33 @@ int proc_fd_permission(struct user_namespace *mnt_userns,
return rv;
}
+int proc_fd_getattr(struct user_namespace *mnt_userns,
+ const struct path *path, struct kstat *stat,
+ u32 request_mask, unsigned int query_flags)
+{
+ struct inode *inode = d_inode(path->dentry);
+ struct proc_dir_entry *de = PDE(inode);
+
+ if (de) {
+ nlink_t nlink = READ_ONCE(de->nlink);
+
+ if (nlink > 0)
+ set_nlink(inode, nlink);
+ }
+
+ generic_fillattr(&init_user_ns, inode, stat);
+
+ /* If it's a directory, put the number of open fds there */
+ if (S_ISDIR(inode->i_mode))
+ stat->size = proc_readfd_count(inode);
+
+ return 0;
+}
+
const struct inode_operations proc_fd_inode_operations = {
.lookup = proc_lookupfd,
.permission = proc_fd_permission,
+ .getattr = proc_fd_getattr,
.setattr = proc_setattr,
};
--
2.37.2
next reply other threads:[~2022-09-16 23:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-16 23:08 Ivan Babrou [this message]
2022-09-17 0:01 ` [RFC] proc: report open files as size in stat() for /proc/pid/fd Andrew Morton
2022-09-17 0:28 ` Ivan Babrou
2022-09-17 7:15 ` Alexey Dobriyan
2022-09-17 18:32 ` Ivan Babrou
2022-09-19 12:30 ` Alexey Dobriyan
2022-09-19 22:03 ` Ivan Babrou
2022-09-19 8:18 ` Christian Brauner
2022-09-17 15:31 ` Theodore Ts'o
2022-09-17 18:32 ` Ivan Babrou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220916230853.49056-1-ivan@cloudflare.com \
--to=ivan@cloudflare.com \
--cc=akpm@linux-foundation.org \
--cc=kaleshsingh@google.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).