All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Chen <tim.c.chen@linux.intel.com>
To: Mateusz Guzik <mjguzik@gmail.com>, Yu Ma <yu.ma@intel.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	 tim.c.chen@intel.com, pan.deng@intel.com, tianyou.li@intel.com
Subject: Re: [PATCH 3/3] fs/file.c: move sanity_check from alloc_fd() to put_unused_fd()
Date: Mon, 17 Jun 2024 10:55:17 -0700	[thread overview]
Message-ID: <fd4eb382a87baed4b49e3cf2cd25e7047f9aede2.camel@linux.intel.com> (raw)
In-Reply-To: <lzotoc5jwq4o4oij26tnzm5n2sqwqgw6ve2yr3vb4rz2mg4cee@iysfvyt77gkx>

On Sat, 2024-06-15 at 07:07 +0200, Mateusz Guzik wrote:
> On Sat, Jun 15, 2024 at 06:41:45AM +0200, Mateusz Guzik wrote:
> > On Fri, Jun 14, 2024 at 12:34:16PM -0400, Yu Ma wrote:
> > > alloc_fd() has a sanity check inside to make sure the FILE object mapping to the
> > 
> > Total nitpick: FILE is the libc thing, I would refer to it as 'struct
> > file'. See below for the actual point.
> > 
> > > Combined with patch 1 and 2 in series, pts/blogbench-1.1.0 read improved by
> > > 32%, write improved by 15% on Intel ICX 160 cores configuration with v6.8-rc6.
> > > 
> > > Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
> > > Signed-off-by: Yu Ma <yu.ma@intel.com>
> > > ---
> > >  fs/file.c | 14 ++++++--------
> > >  1 file changed, 6 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/fs/file.c b/fs/file.c
> > > index a0e94a178c0b..59d62909e2e3 100644
> > > --- a/fs/file.c
> > > +++ b/fs/file.c
> > > @@ -548,13 +548,6 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags)
> > >  	else
> > >  		__clear_close_on_exec(fd, fdt);
> > >  	error = fd;
> > > -#if 1
> > > -	/* Sanity check */
> > > -	if (rcu_access_pointer(fdt->fd[fd]) != NULL) {
> > > -		printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd);
> > > -		rcu_assign_pointer(fdt->fd[fd], NULL);
> > > -	}
> > > -#endif
> > >  
> > 
> > I was going to ask when was the last time anyone seen this fire and
> > suggest getting rid of it if enough time(tm) passed. Turns out it does
> > show up sometimes, latest result I found is 2017 vintage:
> > https://groups.google.com/g/syzkaller-bugs/c/jfQ7upCDf9s/m/RQjhDrZ7AQAJ
> > 
> > So you are moving this to another locked area, but one which does not
> > execute in the benchmark?
> > 
> > Patch 2/3 states 28% read and 14% write increase, this commit message
> > claims it goes up to 32% and 15% respectively -- pretty big. I presume
> > this has to do with bouncing a line containing the fd.
> > 
> > I would argue moving this check elsewhere is about as good as removing
> > it altogether, but that's for the vfs overlords to decide.
> > 
> > All that aside, looking at disasm of alloc_fd it is pretty clear there
> > is time to save, for example:
> > 
> > 	if (unlikely(nr >= fdt->max_fds)) {
> > 		if (fd >= end) {
> > 			error = -EMFILE;
> > 			goto out;
> > 		}
> > 		error = expand_files(fd, fd);
> > 		if (error < 0)
> > 			goto out;
> > 		if (error)
> > 			goto repeat;
> > 	}
> > 
> 
> Now that I wrote it I noticed the fd < end check has to be performed
> regardless of max_fds -- someone could have changed rlimit to a lower
> value after using a higher fd. But the main point stands: the call to
> expand_files and associated error handling don't have to be there.

To really prevent someone from mucking with rlimit, we should probably
take the task_lock to prevent do_prlimit() racing with this function.

task_lock(current->group_leader);

Tim

> 
> > This elides 2 branches and a func call in the common case. Completely
> > untested, maybe has some brainfarts, feel free to take without credit
> > and further massage the routine.
> > 
> > Moreover my disasm shows that even looking for a bit results in
> > a func call(!) to _find_next_zero_bit -- someone(tm) should probably
> > massage it into another inline.
> > 
> > After the above massaging is done and if it turns out the check has to
> > stay, you can plausibly damage-control it with prefetch -- issue it
> > immediately after finding the fd number, before any other work.
> > 
> > All that said, by the above I'm confident there is still *some*
> > performance left on the table despite the lock.
> > 
> > >  out:
> > >  	spin_unlock(&files->file_lock);
> > > @@ -572,7 +565,7 @@ int get_unused_fd_flags(unsigned flags)
> > >  }
> > >  EXPORT_SYMBOL(get_unused_fd_flags);
> > >  
> > > -static void __put_unused_fd(struct files_struct *files, unsigned int fd)
> > > +static inline void __put_unused_fd(struct files_struct *files, unsigned int fd)
> > >  {
> > >  	struct fdtable *fdt = files_fdtable(files);
> > >  	__clear_open_fd(fd, fdt);
> > > @@ -583,7 +576,12 @@ static void __put_unused_fd(struct files_struct *files, unsigned int fd)
> > >  void put_unused_fd(unsigned int fd)
> > >  {
> > >  	struct files_struct *files = current->files;
> > > +	struct fdtable *fdt = files_fdtable(files);
> > >  	spin_lock(&files->file_lock);
> > > +	if (unlikely(rcu_access_pointer(fdt->fd[fd]))) {
> > > +		printk(KERN_WARNING "put_unused_fd: slot %d not NULL!\n", fd);
> > > +		rcu_assign_pointer(fdt->fd[fd], NULL);
> > > +	}
> > >  	__put_unused_fd(files, fd);
> > >  	spin_unlock(&files->file_lock);
> > >  }
> 


  reply	other threads:[~2024-06-17 17:55 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14 16:34 [PATCH 0/3] fs/file.c: optimize the critical section of Yu Ma
2024-06-14 16:34 ` [PATCH 1/3] fs/file.c: add fast path in alloc_fd() Yu Ma
2024-06-15  6:31   ` Mateusz Guzik
2024-06-16  4:01     ` Ma, Yu
2024-06-17 17:49     ` Tim Chen
2024-06-19 10:36   ` David Laight
2024-06-19 17:09     ` Ma, Yu
2024-06-14 16:34 ` [PATCH 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-06-14 16:34 ` [PATCH 3/3] fs/file.c: move sanity_check from alloc_fd() to put_unused_fd() Yu Ma
2024-06-15  4:41   ` Mateusz Guzik
2024-06-15  5:07     ` Mateusz Guzik
2024-06-17 17:55       ` Tim Chen [this message]
2024-06-17 17:59         ` Mateusz Guzik
2024-06-17 18:04         ` Tim Chen
2024-06-18  8:35           ` Michal Hocko
2024-06-18  9:06             ` Mateusz Guzik
2024-06-18 20:40             ` Tim Chen
2024-06-16  3:47     ` Ma, Yu
2024-06-17 11:23       ` Mateusz Guzik
2024-06-17 17:22         ` Ma, Yu
2024-06-17  8:36     ` Christian Brauner
2024-06-22 15:49 ` [PATCH v2 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-06-22 15:49   ` [PATCH v2 1/3] fs/file.c: add fast path in alloc_fd() Yu Ma
2024-06-25 11:52     ` Jan Kara
2024-06-25 12:53       ` Jan Kara
2024-06-25 15:33         ` Ma, Yu
2024-06-26 11:54           ` Jan Kara
2024-06-26 16:43             ` Tim Chen
2024-06-26 16:52               ` Tim Chen
2024-06-27 12:09                 ` Jan Kara
2024-06-27 12:20                   ` Mateusz Guzik
2024-06-27 16:21                   ` Tim Chen
2024-06-26 19:13             ` Mateusz Guzik
2024-06-27 14:03               ` Jan Kara
2024-06-27 15:33               ` Christian Brauner
2024-06-27 18:27                 ` Ma, Yu
2024-06-27 19:59                   ` Mateusz Guzik
2024-06-28  9:12                     ` Jan Kara
2024-06-29 15:41                       ` Ma, Yu
2024-06-29 15:46                         ` Mateusz Guzik
2024-06-29 14:23                     ` Ma, Yu
2024-06-22 15:49   ` [PATCH v2 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-06-25 11:54     ` Jan Kara
2024-06-25 15:41       ` Ma, Yu
2024-06-22 15:49   ` [PATCH v2 3/3] fs/file.c: remove sanity_check from alloc_fd() Yu Ma
2024-06-25 12:08     ` Jan Kara
2024-06-25 13:09       ` Mateusz Guzik
2024-06-25 13:11         ` Mateusz Guzik
2024-06-25 13:30           ` Jan Kara
2024-06-26 13:10             ` Christian Brauner
2024-07-03 14:33 ` [PATCH v3 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-03 14:33   ` [PATCH v3 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-07-03 14:34     ` Christian Brauner
2024-07-03 14:46       ` Ma, Yu
2024-07-04 10:11       ` Jan Kara
2024-07-04 14:45         ` Ma, Yu
2024-07-04 15:41           ` Jan Kara
2024-07-03 14:33   ` [PATCH v3 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-03 14:33   ` [PATCH v3 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-03 14:17     ` Mateusz Guzik
2024-07-03 14:28       ` Ma, Yu
2024-07-04 10:07       ` Jan Kara
2024-07-04 10:03     ` Jan Kara
2024-07-04 14:50       ` Ma, Yu
2024-07-04 17:44     ` Mateusz Guzik
2024-07-04 21:55       ` Jan Kara
2024-07-05  7:56         ` Ma, Yu
2024-07-09  8:32           ` Ma, Yu
2024-07-09 10:17             ` Mateusz Guzik
2024-07-10 23:40               ` Tim Chen
2024-07-11  9:27                 ` Ma, Yu
2024-07-13  2:39 ` [PATCH v4 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-13  2:39   ` [PATCH v4 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-07-16 11:11     ` Jan Kara
2024-07-13  2:39   ` [PATCH v4 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-13  2:39   ` [PATCH v4 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-16 11:19     ` Jan Kara
2024-07-16 12:37       ` Ma, Yu
2024-07-17 14:50 ` [PATCH v5 0/3] fs/file.c: optimize the critical section of file_lock in Yu Ma
2024-07-17 14:50   ` [PATCH v5 1/3] fs/file.c: remove sanity_check and add likely/unlikely in alloc_fd() Yu Ma
2024-08-06 13:44     ` kernel test robot
2024-08-14 21:38     ` Al Viro
2024-08-15  2:49       ` Ma, Yu
2024-08-15  3:45         ` Al Viro
2024-08-15  8:34           ` Ma, Yu
2024-10-31  7:42           ` Mateusz Guzik
2024-10-31 10:14             ` Christian Brauner
2024-07-17 14:50   ` [PATCH v5 2/3] fs/file.c: conditionally clear full_fds Yu Ma
2024-07-17 14:50   ` [PATCH v5 3/3] fs/file.c: add fast path in find_next_fd() Yu Ma
2024-07-19 17:53     ` Mateusz Guzik
2024-07-20 12:57       ` Ma, Yu
2024-07-20 14:22         ` Mateusz Guzik
2024-08-06 13:48     ` kernel test robot
2024-07-22 15:02   ` [PATCH v5 0/3] fs/file.c: optimize the critical section of file_lock in Christian Brauner
2024-08-01 19:13     ` Al Viro
2024-08-02 11:04       ` Christian Brauner
2024-08-02 14:22         ` Al Viro
2024-08-05  6:56           ` Christian Brauner
2024-08-12  1:31             ` Ma, Yu
2024-08-12  2:40               ` Al Viro
2024-08-12 15:09                 ` Ma, Yu
2024-11-06 17:44                 ` Jan Kara
2024-11-06 17:59                   ` Al Viro

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=fd4eb382a87baed4b49e3cf2cd25e7047f9aede2.camel@linux.intel.com \
    --to=tim.c.chen@linux.intel.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    --cc=pan.deng@intel.com \
    --cc=tianyou.li@intel.com \
    --cc=tim.c.chen@intel.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yu.ma@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.