[linux-cifs-client] Re: sendmsg blocking with sendtimeout vs. non-blocking

[Steve French]

A few comments - you need a warmup longer than 1 second, and a test run
longer than 5 seconds. A 100 second test run is probably ok - we need the
"before and after" comparison (ie compare the performance with the patch and
umount and compare the performance with noautotune turned on (old
behavior).   But in any case something looks wrong - a performance of
1.40MB/sec
to Samba is worse than I would expect.  Also please try it with more
simulated clients (e.g. 50)

With dbench 3.04 I am getting more than double what you got with 1 client,
although my system could be a bit faster.

Also can you make sure that you are running current code.  I had hoped that
the

/bin/rm: cannot remove directory
`/mnt/smb_r/clients/client0/~
>
> dmtmp/PARADOX': Directory not empty


error would go away with the fixes Jeff and I did to delete on close (it may
be that this version of dbench keeps files open when it tries to delete them
and then does not close them before the directory is removed thus delete on
close doesn't help).

You should probably be running dbench 4 instead


On Fri, Oct 24, 2008 at 10:02 AM, Shirish Pargaonkar <
shirishpargaonkar at gmail.com> wrote:

> Steve,
>
> Here is a run against a samba share
>
> usr/src/dbench/dbench-3.04 # ./dbench -s -S -t 5s -D /mnt/smb_n -c
> client.txt 1
> dbench version 3.04 - Copyright Andrew Tridgell 1999-2004
>
> Running for 5 seconds with load 'client.txt' and minimum warmup 1 secs
> 1 clients started
>   1        12     0.00 MB/sec  warmup   1 sec
>   1        12     0.00 MB/sec  warmup  24 sec
>   1       102     2.82 MB/sec  execute   1 sec
>   1       232     0.37 MB/sec  cleanup  19 sec
> /bin/rm: cannot remove directory
> `/mnt/smb_n/clients/client0/~dmtmp/COREL': Directory not empty
>   1       232     0.35 MB/sec  cleanup  20 sec
>
> Throughput 1.39629 MB/sec (sync open) (sync dirs) 1 procs
>
>
> And here is against a Windows XP share
>
> :/usr/src/dbench/dbench-3.04 # ./dbench -s -S -t 5s -D /mnt/smb_r -c
> client.txt 1
> dbench version 3.04 - Copyright Andrew Tridgell 1999-2004
>
> Running for 5 seconds with load 'client.txt' and minimum warmup 1 secs
> 1 clients started
>   1       132     3.01 MB/sec  execute   1 sec
>   1       207     2.68 MB/sec  execute   2 sec
>   1       284     2.61 MB/sec  execute   3 sec
>   1       357     2.51 MB/sec  execute   4 sec
>   1       418     2.40 MB/sec  cleanup   5 sec
>   1       418     2.01 MB/sec  cleanup   6 sec
>   1       418     1.72 MB/sec  cleanup   7 sec
>   1       418     1.51 MB/sec  cleanup   8 sec
>   1       418     1.34 MB/sec  cleanup   9 sec
>   1       418     1.20 MB/sec  cleanup  10 sec
>   1       418     1.10 MB/sec  cleanup  11 sec
>   1       418     1.00 MB/sec  cleanup  12 sec
>   1       418     0.93 MB/sec  cleanup  13 sec
>   1       418     0.86 MB/sec  cleanup  14 sec
>   1       418     0.80 MB/sec  cleanup  15 sec
>   1       418     0.75 MB/sec  cleanup  16 sec
>   1       418     0.71 MB/sec  cleanup  17 sec
>   1       418     0.67 MB/sec  cleanup  18 sec
>   1       418     0.63 MB/sec  cleanup  19 sec
>   1       418     0.60 MB/sec  cleanup  20 sec
>   1       418     0.57 MB/sec  cleanup  21 sec
>   1       418     0.55 MB/sec  cleanup  22 sec
>   1       418     0.52 MB/sec  cleanup  23 sec
>   1       418     0.50 MB/sec  cleanup  24 sec
> /bin/rm: cannot remove directory
> `/mnt/smb_r/clients/client0/~dmtmp/PARADOX': Directory not empty
>   1       418     0.49 MB/sec  cleanup  24 sec
>
> Throughput 2.40957 MB/sec (sync open) (sync dirs) 1 procs
>
>
> And the testrun still running with your patch.
>
> Regards,
>
> Shirish
>
> On Fri, Oct 24, 2008 at 9:23 AM, Steve French <smfrench at gmail.com> wrote:
> >
> >
> > On Fri, Oct 24, 2008 at 7:53 AM, Neil Horman <nhorman at redhat.com> wrote:
> >>
> >>  The correct solution is to read data out of the socket into a temporary
> >> buffer that you allocate in the cifs code, and loop repetatively calling
> >> recv[msg|from] until such time as the entire message has been read.
> >>
> >>
> > That is what the cifs code does in cifs_demultiplex_thread.
> >
> > Shirish,
> > If we can verify that performance does not appear to be impacted (e.g.
> some
> > dbench runs against remote server and also against localhost/samba)  when
> > removing the few lines of code in (cifs's) ipv4_connect in which cifs
> sets
> > sndbuf/rcvbuf (we never set them in the case fortunately) - then I will
> > remove those lines immediately (and I am ok with not having a mount
> option
> > to turn off the autotuning ie revert to old behavior)
> >
> >
> >
> > --
> > Thanks,
> >
> > Steve
> >
>



-- 
Thanks,

Steve
-------------- next part --------------
HTML attachment scrubbed and removed