On Fri, Mar 25, 2022 at 09:54:21AM +0100, Greg KH wrote:

On Fri, Mar 25, 2022 at 09:46:46AM +0100, Karel Zak wrote:

quoted

On Thu, Mar 24, 2022 at 09:44:38AM +0100, Miklos Szeredi wrote:

quoted

quoted

If so, have you benchmarked lsof using this new interface?

Not yet.  Looked yesterday at both lsof and procps source code, and
both are pretty complex and not easy to plug in a new interface.   But
I've not yet given up...

I can imagine something like getvalues(2) in lsblk (based on /sys) or
in lsfd (based on /proc; lsof replacement). The tools have defined set
of information to read from kernel, so gather all the requests to the
one syscall for each process or block device makes sense and it will
dramatically reduce number of open+read+close syscalls.

And do those open+read+close syscalls actually show up in measurements?

Again, I tried to find a real-world application that turning those 3
into 1 would matter, and I couldn't.  procps had no decreased system
load that I could notice.  I'll mess with lsof but that's really just a
stress-test, not anything that is run all the time, right?

Right, the speed of ps(1) or lsof(1) is not important. IMHO the current
discussion about getvalues() goes in wrong direction :-)  

I guess the primary motivation is not to replace open+read+close, but
provide to userspace something usable to get information from mount
table, because the current /proc/#/mountinfo and notification by
poll() is horrible.

Don't forget that the previous attempt was fsinfo() from David Howells
(unfortunately, it was too complex and rejected by Linus).

And as others have said, using io_uring() would also solve the 3 syscall
issue, but no one seems to want to convert these tools to use that,
which implies that it's not really an issue for anyone :)

OK, I'll think about it :-)

    Karel

-- 
 Karel Zak  [off-list ref]
 http://karelzak.blogspot.com