archive mirror
 help / color / mirror / Atom feed
From: Ronnie Sahlberg <>
To: Steve French <>
Cc: CIFS <>,
	samba-technical <>,
	LKML <>,
	linux-fsdevel <>,
	ronnie sahlberg <>
Subject: Re: Overview of performance improvements of recent SMB3 compounding patches
Date: Wed, 22 Aug 2018 21:44:39 -0400 (EDT)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

We also have stat() that drops from 6 to 2 roundtrips.

For metadata I think the only remaining low hanging fruit is readdir().
Currently in cifs.ko scanning a directory takes a minimum of 4 roundtrips :

query and get data
query and get the error STATUS_NO_MORE_FILES

For small-ish directories (the common case I expect will be that almost all directories will fit in one reply of data)
we can cut this down to just a single roundtrip by using the compound :

open; query; query; close

If the second query fails with the error above we know we are done and we finished in a single

The drawback is for the rare cases where the directory did not fit in the reply, then
we will have to throw all the data away and re-start from scratch using the old loop thus making all large directory scans
even slower than they are right now, well just one roundtrip slower but still.
(Technically, the protocol does support re-opening a directory and resuming at a specific FileIndex  but it is not implemented server-side.)

I think it will still be worth it if we can get the common case to drop from 4 to 1 roundtrip.

It will involve touching cifs_readdir() which is hairy code but if someone would want to tackle this I think there is opportunity to make
a huge impact on directory listing performance.

ronnie sahlberg

----- Original Message -----
> From: "Steve French" <>
> To: "CIFS" <>, "samba-technical" <>, "LKML"
> <>, "linux-fsdevel" <>, "ronnie sahlberg"
> <>
> Sent: Thursday, 23 August, 2018 5:28:01 AM
> Subject: Re: Overview of performance improvements of recent SMB3 compounding patches
> Continuing the experiments with Ronnie's patches show additional
> promising performance results from other common scenarios:
> Very good news that the number of roundtrips (request/response pairs
> to the server) has dropped so substantially.  Reducing latency, and
> allowing the server to more efficiently process the requests leads to
> much better performance for these common operations:
> - rename goes from 9 request/response pairs to 5 ("mv /mnt/file /mnt/file1")
> - hardlink goes from 8 to only 3 (!)  ("ln /mnt/file1 /mnt/file2")
> - symlink (with mfsymlinks enabled) goes from 11 to 9 ("ln -s
> /mnt/file1 /mnt/file3")
> - touch (existing file) 6 down to 4
> In current kernel we benefit from compounding now on stafs ("stat -f
> /mnt"), and in the earlier note I described the improvements in
> create, unlink, mkdir and rmdir which were also awesome.
> This is very exciting.
> On Tue, Aug 21, 2018 at 1:24 PM Steve French <> wrote:
> >
> > In experiments today with Ronnie's most recent compounding patches I
> > see the expected significant improvements in create/mkdir/unlink/rmdir
> > operations over SMB3 mounts (tests were to Samba but would be similar
> > to all modern servers).  See below:
> >
> > "touch /mnt/file"  goes from 6 request/response pairs to 4 with
> > Ronnie's compounding patches
> > "rm /mnt/file" from 5 to 2 request/response pairs
> > "mkdir /mnt/newdir" 6 pairs to 3 pairs
> > "rmdir /mnt/newdir" 6 pairs down to 2 pairs
> >
> > Good job Ronnie!
> > --
> > Thanks,
> >
> > Steve
> --
> Thanks,
> Steve

      reply	other threads:[~2018-08-23  5:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-21 18:24 Overview of performance improvements of recent SMB3 compounding patches Steve French
2018-08-22 19:28 ` Steve French
2018-08-23  1:44   ` Ronnie Sahlberg [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).