Strange performance issue with grep -r -i as non-root user

[illoai at gmail.com]

On 5 March 2011 21:05, Jeremy Chadwick <freebsd at jdc.parodius.com> wrote:
> On Sat, Mar 05, 2011 at 08:49:46PM -0500, illoai at gmail.com wrote:
>> On 5 March 2011 20:43, Jeremy Chadwick <freebsd at jdc.parodius.com> 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 (starting
>> >> > 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 when I
>> >> > found out the behaviour changes depending on if you're a user or root.
>> >> >
>> >> > 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 without -i
>> >>
>> >>   From your results below, I think you mean *80* x slower!
>> >
>> > Oops; yes, typo on my part.  I was never any good at math either!  ;-)
>> >
>> >> > - grep -r string /usr/src, as root, is fast
>> >> > - grep -r -i string /usr/src, as root, is fast
>> >>
>> >>   I can not reproduce this on 7.3-RELEASE-p4; I get consistent results
>> >> between root and non-root, with -i being only marginally slower (about
>> >> 15%) for each; results below.
>> >
>> > Your results look more or less like what I see on the 4th system (the
>> > 7.0-STABLE one).  I believe the speed difference there (and on your
>> > system) is justified, as I would imagine strcasecmp() a tiny bit slower
>> > than strcmp().  But an 80x slowdown is completely unacceptable,
>> > especially given the conditions.
>> >
>> > My first thought was "compiler optimisation bug?", which I suppose could
>> > 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 going
>> > on with CAM?  Sadly I cannot (for many reasons) get rid of ahci.ko on
>> > 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).  Which 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=18 function=0 handle=\_SB_.PCI0.SATA
dev.ahci.0.%pnpinfo: vendor=0x1002 device=0x4380 subvendor=0x1179
subdevice=0xff68 class=0x01018f
dev.ahci.0.%parent: pci0
dev.ahcich.0.%desc: AHCI channel
dev.ahcich.0.%driver: ahcich
dev.ahcich.0.%location: channel=0
dev.ahcich.0.%parent: ahci0
dev.ahcich.1.%desc: AHCI channel
dev.ahcich.1.%driver: ahcich
dev.ahcich.1.%location: channel=1
dev.ahcich.1.%parent: ahci0
dev.ahcich.2.%desc: AHCI channel
dev.ahcich.2.%driver: ahcich
dev.ahcich.2.%location: channel=2
dev.ahcich.2.%parent: ahci0
dev.ahcich.3.%desc: AHCI channel
dev.ahcich.3.%driver: ahcich
dev.ahcich.3.%location: channel=3
dev.ahcich.3.%parent: ahci0

HTH

-- 
--