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

[Jeremy Chadwick]

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?

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.               PGP 4BD6C0CB |