On Fri, Jul 03, 2009 at 02:04:50AM +0200, Max Laier wrote:
quoted text
> On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote:
> > I'm observing some heavy slowdown seen with md5 test on PowerPC:
> >
> > 1. On the MPC8572 machine with today's HEAD I'm getting:
> >
> > # md5 -t
> > MD5 time trial. Digesting 100000 10000-byte blocks ... done
> > Digest =3D 766a2bb5d24bddae466c572bcabca3ee
> > Time =3D 36.930565 seconds
> > Speed =3D 27077842.000000 bytes/second
> >
> > 2. While a couple of months back it yielded 6x shorter times on this
> > very same hardware, like this one:
> >
> > # md5 -t
> > MD5 time trial. Digesting 100000 10000-byte blocks ... done
> > Digest =3D 766a2bb5d24bddae466c572bcabca3ee
> > Time =3D 6.027277 seconds
> > Speed =3D 165912400.000000 bytes/second
> >
> > Timers work fine, the slowdown is real. I don't know if this is
> > PowerPC related, and was wondering if anybody observed something
> > similar on other archs perhaps? Any suggestions what could be causing
> > this or where to look? I cannot see immediate suspects in the arch/
> > platform code.
>=20
> "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this mailing list=
=20
quoted text
> reports something that might be related.  It seems there is a patch=20
> available, but not committed yet.  Though I'm not sure about the nature o=
f=20
quoted text
> the problem exactly.  Jeff?

I want to make some points clear to avoid a confusion and spread of FUD.
It seems we have at least three issues, all different:
1. Syscalls slowdown on amd64. To see this, you need to microbenchmark
   syscall enter/leave sequence. I doubt that it can be seen on any
   load except while (1) {getpid();} loops or such. The issue is valid
   _only_ for amd64.
   I developed the patch with the input from Jeff who confirmed that
   this slowdown is solved by the change.
2. There are enough independent reports of i/o slowdown to believe that
   some problem is real; but we have not seen numbers or detailed
   configurations or (most desirable) the revision after which the
   slowdown started. Note the i/o part.

This report is for PPC (right ?) and for workload that is purely
CPU-bounded.

Please do not mix different issues.