From: David Laight <David.Laight@ACULAB.COM>
To: 'Yu Ma' <yu.ma@intel.com>,
"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
"brauner@kernel.org" <brauner@kernel.org>,
"jack@suse.cz" <jack@suse.cz>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"tim.c.chen@linux.intel.com" <tim.c.chen@linux.intel.com>,
"tim.c.chen@intel.com" <tim.c.chen@intel.com>,
"pan.deng@intel.com" <pan.deng@intel.com>,
"tianyou.li@intel.com" <tianyou.li@intel.com>
Subject: RE: [PATCH 1/3] fs/file.c: add fast path in alloc_fd()
Date: Wed, 19 Jun 2024 10:36:47 +0000 [thread overview]
Message-ID: <218ccf06e7104eb580023fb69c395d3e@AcuMS.aculab.com> (raw)
In-Reply-To: <20240614163416.728752-2-yu.ma@intel.com>
From: Yu Ma <yu.ma@intel.com>
> Sent: 14 June 2024 17:34
>
> There is available fd in the lower 64 bits of open_fds bitmap for most cases
> when we look for an available fd slot. Skip 2-levels searching via
> find_next_zero_bit() for this common fast path.
>
> Look directly for an open bit in the lower 64 bits of open_fds bitmap when a
> free slot is available there, as:
> (1) The fd allocation algorithm would always allocate fd from small to large.
> Lower bits in open_fds bitmap would be used much more frequently than higher
> bits.
> (2) After fdt is expanded (the bitmap size doubled for each time of expansion),
> it would never be shrunk. The search size increases but there are few open fds
> available here.
> (3) There is fast path inside of find_next_zero_bit() when size<=64 to speed up
> searching.
>
> With the fast path added in alloc_fd() through one-time bitmap searching,
> pts/blogbench-1.1.0 read is improved by 20% and write by 10% 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 | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/fs/file.c b/fs/file.c
> index 3b683b9101d8..e8d2f9ef7fd1 100644
> --- a/fs/file.c
> +++ b/fs/file.c
> @@ -510,8 +510,13 @@ static int alloc_fd(unsigned start, unsigned end, unsigned flags)
> if (fd < files->next_fd)
> fd = files->next_fd;
>
> - if (fd < fdt->max_fds)
> + if (fd < fdt->max_fds) {
> + if (~fdt->open_fds[0]) {
> + fd = find_next_zero_bit(fdt->open_fds, BITS_PER_LONG, fd);
> + goto success;
> + }
> fd = find_next_fd(fdt, fd);
> + }
Hmm...
How well does that work when the initial fd is > 64?
Since there is exactly one call to find_next_fd() and it is static and should
be inlined doesn't this optimisation belong inside find_next_fd().
Plausibly find_next_fd() just needs rewriting.
Or, possibly. even inside an inlinable copy of find_next_zero-bit()
(although a lot of callers won't be 'hot' enough for the inlined bloat
being worth while).
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-06-19 10:37 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 [this message]
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
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=218ccf06e7104eb580023fb69c395d3e@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pan.deng@intel.com \
--cc=tianyou.li@intel.com \
--cc=tim.c.chen@intel.com \
--cc=tim.c.chen@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®