From owner-freebsd-amd64@freebsd.org Fri Mar 18 22:55:44 2016 Return-Path: Delivered-To: freebsd-amd64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87FE3AD44B0 for ; Fri, 18 Mar 2016 22:55:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E76B1332 for ; Fri, 18 Mar 2016 22:55:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2IMtitT008345 for ; Fri, 18 Mar 2016 22:55:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-amd64@FreeBSD.org Subject: [Bug 208130] smbfs is slow because it (apparently) doesn't do any caching/buffering Date: Fri, 18 Mar 2016 22:55:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: noah.bergbauer@tum.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 19 Mar 2016 01:05:07 +0000 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 22:55:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208130 Bug ID: 208130 Summary: smbfs is slow because it (apparently) doesn't do any caching/buffering Product: Base System Version: 10.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: noah.bergbauer@tum.de CC: freebsd-amd64@FreeBSD.org CC: freebsd-amd64@FreeBSD.org I set up an smbfs mount on FreeBSD 10.2-RELEASE today and was noticed that = it's very slow. How slow? Some numbers: Reading a 600MB file from the share with= dd reports around 1 MB/s while doing the same in a Linux VM running inside bhy= ve on this very same machine yields a whopping 100 MB/s. I conclude that the S= MB server is irrelevant in this case. There's a recent [discussion](https://lists.freebsd.org/pipermail/freebsd-hackers/2015-Novem= ber/048597.html) about this on freebsd-hackers which reveals an interesting detail: The situation can be improved massivley up to around 60MB/s on the FreeBSD side just by using a larger dd buffer size (e.g. 1MB). Interestingly, using very small buffers has only negligible impact on Linux (until the whole affair g= ets CPU-bottlenecked of course). I know little about SMB but a quick network traffic analysis gives some insights: FreeBSD's smbfs seems to translate every read() call from dd dire= ctly into an SMB request. So with a small buffer size of e.g. 1k, something like this seems to happen: * client requests 1k of data * client waits for a response (network round-trip) * client receives response * client hands data to dd which then issues another read() * client requests 1k of data * ... Note how we're spending most of our time waiting for network round-trips. Because a bigger buffer means larger SMB requests, this obviously leads to higher network saturation and less wasted time. I'm unable to spot a similar pattern on Linux. Here, a steady flow of data = is maintained even with small buffer sizes, so apparently some caching/bufferi= ng must be happening. Linux's cifs has a "cache" option and indeed, disabling = it produces exactly the same performance (and network) behavior I'm seeing on FreeBSD. So to sum things up: The fact that smbfs doesn't have anything like Linux's cache causes a 100-fold performance hit. Obviously, that's a problem. --=20 You are receiving this mail because: You are on the CC list for the bug.=