[linux-cifs-client] Re: [PATCH 6/6] cifs: don't retry on blocking sends

[Jeff Layton]

On Mon, 1 Dec 2008 12:06:16 -0600
"Steve French" <smfrench at gmail.com> wrote:

> On Mon, Dec 1, 2008 at 12:00 PM, Jeff Layton <jlayton at redhat.com> wrote:
> > On Mon, 1 Dec 2008 11:41:18 -0600
> > "Steve French" <smfrench at gmail.com> wrote:
> >
> >> On Mon, Dec 1, 2008 at 6:35 AM, Jeff Layton <jlayton at redhat.com> wrote:
> >> > While we're at it, my testing shows that blocking sends give better
> >> > performance in general than non-blocking. Is there any reason to keep
> >> > non-blocking sends in this code at all? As a mount option, it's not
> >> > very helpful -- most users are going to have no idea when to use it.
> >>
> >> I was planning on removing the non-blocking sends in 2.6.29, but my
> >> testing a few weeks ago to Samba 3, especially on localhost, showed a
> >> slight performance gain with non-blocking sends.   Until this can be
> >> proved false, I think we need to keep them.
> >>
> >
> > How much performance gain were you seeing? I saw the exact opposite -- sightly better performance with blocking sends, but the difference was so small that it really didn't matter (<<1%).
> 
> Of the four combinations I tried (nonblocking/noautotune,
> blocking/autotune, nonblocking/autotune, blocking/noautotune), the
> nonblocking cases were fastest, but usually by less than 3%.   More
> data needed
> 
> 

I think the problem may be that the sending code is marginally
optimized for the non-blocking case, when it should be the other way
around. When we get an -EAGAIN from a blocking send, we put the thread
to sleep before retrying the send. That's probably hurting performance
somewhat since we use such small timeouts. If you want to retry the
send then you should probably do it immediately without msleep'ing.

--
Jeff Layton <jlayton at redhat.com>