On Wed, Mar 23, 2022 at 02:24:40PM +0100, Miklos Szeredi wrote: > The reason I stated thinking about this is that Amir wanted a per-sb > iostat interface and dumped it into /proc/PID/mountstats. And that is > definitely not the right way to go about this. > > So we could add a statfsx() and start filling in new stuff, and that's > what Linus suggested. But then we might need to add stuff that is not > representable in a flat structure (like for example the stuff that > nfs_show_stats does) and that again needs new infrastructure. > > Another example is task info in /proc. Utilities are doing a crazy > number of syscalls to get trivial information. Why don't we have a > procx(2) syscall? I guess because lots of that is difficult to > represent in a flat structure. Just take the lsof example: tt's doing > hundreds of thousands of syscalls on a desktop computer with just a > few hundred processes. I'm still a bit puzzled about the reason for getvalues(2) beyond, "reduce the number of system calls". Is this a performance argument? If so, have you benchmarked lsof using this new interface? I did a quickie run on my laptop, which currently had 444 process. "lsof /home/tytso > /tmp/foo" didn't take long: % time lsof /home/tytso >& /tmp/foo real 0m0.144s user 0m0.039s sys 0m0.087s And an strace of that same lsof command indicated had 67,889 lines. So yeah, lots of system calls. But is this new system call really going to speed up things by all that much? If the argument is "make it easier to use", what's wrong the solution of creating userspace libraries which abstract away calls to open/read/close a whole bunch of procfs files to make life easier for application programmers? In short, what problem is this new system call going to solve? Each new system call, especially with all of the parsing that this one is going to use, is going to be an additional attack surface, and an additional new system call that we have to maintain --- and for the first 7-10 years, userspace programs are going to have to use the existing open/read/close interface since enterprise kernels stick a wrong for a L-O-N-G time, so any kind of ease-of-use argument isn't really going to help application programs until RHEL 10 becomes obsolete. (Unless you plan to backport this into RHEL 9 beta, but still, waiting for RHEL 9 to become completely EOL is going to be... a while.) So whatever the benefits of this new interface is going to be, I suggest we should be sure that it's really worth it. Cheers, - Ted
