I think this is getting too much fluff traffic at this point, which is partially my fault. I'm buggering off. Overall the patchset looks good, I don't see any technical reasons to avoid merging it. On Sat, Jul 20, 2024 at 2:57 PM Ma, Yu <yu.ma@xxxxxxxxx> wrote: > > > On 7/20/2024 1:53 AM, Mateusz Guzik wrote: > > On Wed, Jul 17, 2024 at 4:24 PM Yu Ma <yu.ma@xxxxxxxxx> wrote: > >> Skip 2-levels searching via find_next_zero_bit() when there is free slot in the > >> word contains next_fd, as: > >> (1) next_fd indicates the lower bound for the first free fd. > >> (2) There is fast path inside of find_next_zero_bit() when size<=64 to speed up > >> searching. > > this is stale -- now the fast path searches up to 64 fds in the lower bitmap > > Nope, this is still valid, as the searching size of the fast path inside > of find_next_fd() is always 64, it will execute the fast path inside of > find_next_zero_bit(). > > > > > >> (3) 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. > >> > >> This fast path is proposed by Mateusz Guzik <mjguzik@xxxxxxxxx>, and agreed by > >> Jan Kara <jack@xxxxxxx>, which is more generic and scalable than previous > >> versions. > > I think this paragraph is droppable. You already got an ack from Jan > > below, so stating he agrees with the patch is redundant. As for me I > > don't think this warrants mentioning. Just remove it, perhaps > > Christian will be willing to massage it by himself to avoid another > > series posting. > > The idea of fast path for the word contains next_fd is from you, > although this patch is small, I think it is reasonable to record here > out of my respect. Appreciate for your guide and comments on this patch, > I've learned a lot on the way of resolving problems :) > > > Regards > > Yu > > >> And on top of patch 1 and 2, it improves pts/blogbench-1.1.0 read by > >> 8% and write by 4% on Intel ICX 160 cores configuration with v6.10-rc7. > >> > >> Reviewed-by: Jan Kara <jack@xxxxxxx> > >> Reviewed-by: Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx> > >> Signed-off-by: Yu Ma <yu.ma@xxxxxxxxx> > >> --- > >> fs/file.c | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/fs/file.c b/fs/file.c > >> index 1be2a5bcc7c4..729c07a4fc28 100644 > >> --- a/fs/file.c > >> +++ b/fs/file.c > >> @@ -491,6 +491,15 @@ static unsigned int find_next_fd(struct fdtable *fdt, unsigned int start) > >> unsigned int maxfd = fdt->max_fds; /* always multiple of BITS_PER_LONG */ > >> unsigned int maxbit = maxfd / BITS_PER_LONG; > >> unsigned int bitbit = start / BITS_PER_LONG; > >> + unsigned int bit; > >> + > >> + /* > >> + * Try to avoid looking at the second level bitmap > >> + */ > >> + bit = find_next_zero_bit(&fdt->open_fds[bitbit], BITS_PER_LONG, > >> + start & (BITS_PER_LONG - 1)); > >> + if (bit < BITS_PER_LONG) > >> + return bit + bitbit * BITS_PER_LONG; > >> > >> bitbit = find_next_zero_bit(fdt->full_fds_bits, maxbit, bitbit) * BITS_PER_LONG; > >> if (bitbit >= maxfd) > >> -- > >> 2.43.0 > >> > > -- Mateusz Guzik <mjguzik gmail.com>
