From owner-freebsd-performance@FreeBSD.ORG  Thu Jan  5 17:46:28 2012
Return-Path: <owner-freebsd-performance@FreeBSD.ORG>
Delivered-To: freebsd-performance@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 9AB6D106564A
	for <freebsd-performance@freebsd.org>;
	Thu,  5 Jan 2012 17:46:28 +0000 (UTC)
	(envelope-from dieterbsd@engineer.com)
Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67])
	by mx1.freebsd.org (Postfix) with SMTP id 434698FC15
	for <freebsd-performance@freebsd.org>;
	Thu,  5 Jan 2012 17:46:28 +0000 (UTC)
Received: (qmail 32135 invoked by uid 0); 5 Jan 2012 17:46:27 -0000
Received: from 67.206.161.160 by rms-us011.v300.gmx.net with HTTP
Content-Type: text/plain; charset="utf-8"
Date: Thu, 05 Jan 2012 12:46:24 -0500
From: "Dieter BSD" <dieterbsd@engineer.com>
Message-ID: <20120105174626.218240@gmx.com>
MIME-Version: 1.0
To: freebsd-performance@freebsd.org
X-Authenticated: #74169980
X-Flags: 0001
X-Mailer: GMX.com Web Mailer
x-registered: 0
Content-Transfer-Encoding: 8bit
X-GMX-UID: pYR3byQ03zOlNR3dAHAhr4x+IGRvbwCX
Subject: Re: cmp(1) has a bottleneck, but where?
X-BeenThere: freebsd-performance@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Performance/tuning <freebsd-performance.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-performance>,
	<mailto:freebsd-performance-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-performance>
List-Post: <mailto:freebsd-performance@freebsd.org>
List-Help: <mailto:freebsd-performance-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-performance>,
	<mailto:freebsd-performance-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 17:46:28 -0000

> Something/somehow it's issuing smaller IOs when using mmap?

On my box, 64K reads.  Using the '-' to avoid mmap it uses
128K.

The big difference I found was that the default mmap case isn't
using read-ahead. So it has to wait on the disk every time.  :-(

Using the '-' to avoid mmap it benefits from read-ahead, but the
default of 8 isn't large enough.  Crank up vfs.read_max and it
becomes cpu bound.  (assuming using 2 disks and not limited by
both disks being on the same wimpy controller)

A) Should the default vfs.read_max be increased?

B) Can the mmap case be fixed?  What is the aledged benefit of
using mmap anyway?  All I've even seen are problems.