amd64 slower than i386 on identical AMD 64 system?
kris at obsecurity.org
Wed Mar 15 18:46:13 UTC 2006
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
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
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
> > > 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20060315/22322a52/attachment.pgp
More information about the freebsd-amd64