From owner-freebsd-stable@FreeBSD.ORG Sun Mar 6 02:11:34 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D82106566C for ; Sun, 6 Mar 2011 02:11:34 +0000 (UTC) (envelope-from illoai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id EC9278FC13 for ; Sun, 6 Mar 2011 02:11:33 +0000 (UTC) Received: by fxm19 with SMTP id 19so3642840fxm.13 for ; Sat, 05 Mar 2011 18:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oHHR88nfPchC9YXQzG5bLLfcuIbsXDn4sxIKpsXD1RA=; b=vRceteSRoyDUa5+BC05AQ9G0Sm2ku1mDIgnTOGXRiBriGL45tpb2ACggeykbMy6mce x05kKiRnb5tkLZr532UyVS6A5f4rAgBjLGNN4FJ0qwwhlMoavVKmi5Ql2ImIrJkryoAa kSLMmyM1xor7Vi5bq1eQwUcXmzHBKHBZKsKfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DcHRETuOdQdGaEELMFKQlVt+6s7CYY3/Wt41rpEOT1ge1NjWPNezeXSDXozKz65rO3 bkmGXtPn7TjmPkea6JfaXLB8MbFvP80l+VCfN/NmrOjuL1Pwv0NjCCVqX9+3eMfczlEO PJuAM6EX/EPd+gKstovp/Y2ZbDjRJQ81Rg25Q= MIME-Version: 1.0 Received: by 10.223.143.86 with SMTP id t22mr2899893fau.78.1299377492803; Sat, 05 Mar 2011 18:11:32 -0800 (PST) Received: by 10.223.96.203 with HTTP; Sat, 5 Mar 2011 18:11:32 -0800 (PST) In-Reply-To: <20110306020546.GA37414@icarus.home.lan> References: <20110305234514.GA34594@icarus.home.lan> <20110306010140.GA90699@lava.net> <20110306014355.GA36763@icarus.home.lan> <20110306020546.GA37414@icarus.home.lan> Date: Sat, 5 Mar 2011 21:11:32 -0500 Message-ID: From: "illoai@gmail.com" To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Strange performance issue with grep -r -i as non-root user X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 02:11:34 -0000 On 5 March 2011 21:05, Jeremy Chadwick wrote: > On Sat, Mar 05, 2011 at 08:49:46PM -0500, illoai@gmail.com wrote: >> On 5 March 2011 20:43, Jeremy Chadwick wrote: >> > On Sat, Mar 05, 2011 at 03:01:40PM -1000, Clifton Royston wrote: >> >> On Sat, Mar 05, 2011 at 03:45:14PM -0800, Jeremy Chadwick wrote: >> >> > This is a strange one, and the more I started debugging it (startin= g >> >> > with truss, comparing fast vs. slow results, where all that appears >> >> > different is read() operations are taking a lot longer -- I haven't= had >> >> > time to check with ktrace yet), the more strange it got: that's whe= n I >> >> > found out the behaviour changes depending on if you're a user or ro= ot. >> >> > >> >> > Easy to reproduce: >> >> > >> >> > - grep -r string /usr/src, as non-root, is fast >> >> > - grep -r -i string /usr/src, as non-root, is 8x slower than withou= t -i >> >> >> >> =A0 From your results below, I think you mean *80* x slower! >> > >> > Oops; yes, typo on my part. =A0I was never any good at math either! = =A0;-) >> > >> >> > - grep -r string /usr/src, as root, is fast >> >> > - grep -r -i string /usr/src, as root, is fast >> >> >> >> =A0 I can not reproduce this on 7.3-RELEASE-p4; I get consistent resu= lts >> >> between root and non-root, with -i being only marginally slower (abou= t >> >> 15%) for each; results below. >> > >> > Your results look more or less like what I see on the 4th system (the >> > 7.0-STABLE one). =A0I believe the speed difference there (and on your >> > system) is justified, as I would imagine strcasecmp() a tiny bit slowe= r >> > than strcmp(). =A0But an 80x slowdown is completely unacceptable, >> > especially given the conditions. >> > >> > My first thought was "compiler optimisation bug?", which I suppose cou= ld >> > still be the case, but I don't know how root vs. non-root would change >> > that behaviour, not to mention only when -i was specified. >> > >> > Using 'truss -d' it looks like the slowdown is happening on read(2), >> > which makes me very concerned, as it could indicate something odd goin= g >> > on with CAM? =A0Sadly I cannot (for many reasons) get rid of ahci.ko o= n >> > any of those 3 systems, so I can't compare stock ata(4) to ahci.ko >> > easily on the same system. >> > >> >> On my 8.2-RELEASE system using ahci (built into the custom >> kernel) I don't notice your observed slowdown, so unless ahci >> is radically different on -STABLE I doubt it's the cause. > > There are two versions of AHCI available in FreeBSD: ahci.ko (which is > AHCI<->CAM) and ataahci.ko (which is AHCI support under ata(4) natively > and does not use CAM). =A0Which of the two are you using? I have device ahci in my kernel, ataahci, not. > sysctl -a | grep ahci dev.ahci.0.%desc: ATI IXP600 AHCI SATA controller dev.ahci.0.%driver: ahci dev.ahci.0.%location: slot=3D18 function=3D0 handle=3D\_SB_.PCI0.SATA dev.ahci.0.%pnpinfo: vendor=3D0x1002 device=3D0x4380 subvendor=3D0x1179 subdevice=3D0xff68 class=3D0x01018f dev.ahci.0.%parent: pci0 dev.ahcich.0.%desc: AHCI channel dev.ahcich.0.%driver: ahcich dev.ahcich.0.%location: channel=3D0 dev.ahcich.0.%parent: ahci0 dev.ahcich.1.%desc: AHCI channel dev.ahcich.1.%driver: ahcich dev.ahcich.1.%location: channel=3D1 dev.ahcich.1.%parent: ahci0 dev.ahcich.2.%desc: AHCI channel dev.ahcich.2.%driver: ahcich dev.ahcich.2.%location: channel=3D2 dev.ahcich.2.%parent: ahci0 dev.ahcich.3.%desc: AHCI channel dev.ahcich.3.%driver: ahcich dev.ahcich.3.%location: channel=3D3 dev.ahcich.3.%parent: ahci0 HTH --=20 --