amd64 slower than i386 on identical AMD 64 system?

[Kris Kennaway]

On Wed, Mar 15, 2006 at 06:01:25AM -0300, JoaoBR wrote:
> On Tuesday 14 March 2006 23:28, Kris Kennaway wrote:
> > On Tue, Mar 14, 2006 at 07:14:54PM -0300, JoaoBR wrote:
> > > I can confirm this too
> > > SMP amd64s are having constant crashes when running >2GB and <4GB of RAM.
> > > In order not getting anything wrong I am talking about X2-SMP
> > > mono-chip-MBs this is not happening on dual-chip-MB with two separate
> > > processors. I run the same hardware as UP-amd64 and it never crashes
> > > Since this crashes are more frequent with IPI_PREEMPTION I have now some
> > > servers under test running without PREEMPTION at all and appearently the
> > > crashes are gone
> >
> > Right, IPI_PREEMPTION is not stable (nor is it enabled by default).
> > Why did you decide to use it?
> >
> 
> for the obvious ... the never-ending-search for better performance
> BTW this option is very bad documented and no hint in NOTES that it may not 
> work

OK.  Just as a general point of common sense: when you find things
that aren't enabled by default, there's almost always a good reason
for this.

Sometimes the reason is clear (driver conflicts with another driver,
etc), but for secret poorly-documented options that change kernel
behaviour it should ring warning bells that it might not be a good
idea to just set and forget.

> > > Overall the amd64-SMP kernels running on X2 processors are extermly
> > > sensitive to non polling NICs and are crashing often. The overall
> > > performance also is bad.
> > > Soon I change this cards into polling ones, seems XL is best, I do not
> > > have crashes anymore.
> > > Funny that single 64bit AMDs are running fine with non polling NICs even
> > > when running a SMP enabled kernel. Soon I put back the X2 ... boom.
> >
> > Crashing with or without the use of broken kernel options?
> 
> without,  SMP kernel but POLLING enabled

OK, please file a bug report including panic traces, etc.  This is
necessary for someone to analyze and (if appropriate) fix your
problem.

> > > My servers are cache servers in first place and I have some web and mail
> > > server running amd64 and the cpu scheduling seems to work well. Overall I
> > > have the impression that the ULE scheduler is giving better performance
> > > on a machine with more than 2MB/s going through
> >
> > You need to be very careful when claiming bad performance: ULE is
> > well-known to perform badly on many workloads.
> >
> 
> well, read again
>  I said here that ULE is giving me BETTER performance

And above in the quoted text you said bad performance, so who knows
what settings you had then :-) Maybe you're blaming something on
polling that is really the fault of ULE.

> > In summary, you need to rule out whether your issues are resulting
> > from a poor choice of non-standard kernel options, or are actually
> > bugs in FreeBSD.
> >
> 
> obvious, but we often do not know all for sure so it's good talking about 
> 
> resuming my experience:
> 
>  SMP with single dual-core processors on standard MBs are sensitive (crashing 
> easily or time-outs) with non polling NICs
> 
> SMP with single dual-core processors are randomly crashing when >2GB and <4GB 
> on standard MBs
> 
> Both issues are not appearing at all when changing the X2 for a standard 
> athlon 64 processor, means same hardware, same OS version and kernel
> 
> Both issues are also not appearing when using the dual-core running same 
> hardware, same os version but UP kernel (only cutting options SMP).
> 
> I understand here that amd64 is still not dealing well with dual-cores and 
> more than 2GB of RAM

It really sounds like it could be a broken BIOS on your system (check
for upgrades).  AFAIK, dual-core systems are not known to have these
problems in general.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20060315/22322a52/attachment.pgp