[RFC,0/2] avoid the extra atomic on a ref when closing a fd

Message

Mateusz Guzik March 4, 2025, 4:36 p.m. UTC

The stock kernel transitioning the file to no refs held penalizes the
caller with an extra atomic to block any increments.

For cases where the file is highly likely to be going away this is
easily avoidable.

The obvious place is the close() system call, patched in 2/2.

But part from that possible callers (to be evaluated):
- clean up after failed open (common)
- close_range
- close on exec
- process exit

So 1/1 adds some routines and 2/2 uses one of them. The rest can be
tackled on later or I can send a v2 with more places sorted out.

In the open+close case the win is very modest because of the following
problems:
- kmem and memcg having terrible performance
- putname using an atomic (I have a wip to whack that)
- open performing an extra ref/unref on the dentry (there are patches to
  do it, including by Al. I'll be mailing about it separately)
- creds using atomics (I have a wip to whack that)
- apparmor using atomics (ditto, same mechanism)

On top of that I have a WIP patch to dodge some of the work at lookup
itself.

All in all there is several % avoidably lost here.

Mateusz Guzik (2):
  file: add fput and file_ref_put routines optimized for use when
    closing a fd
  fs: use fput_close() in close()

 fs/file.c                | 75 ++++++++++++++++++++++++++++++----------
 fs/file_table.c          | 72 +++++++++++++++++++++++++++-----------
 fs/open.c                |  2 +-
 include/linux/file.h     |  2 ++
 include/linux/file_ref.h |  1 +
 5 files changed, 112 insertions(+), 40 deletions(-)