Date: Wed, 15 Mar 2006 13:46:06 -0500 From: Kris Kennaway <kris@obsecurity.org> To: JoaoBR <joao@matik.com.br> Cc: freebsd-amd64@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: amd64 slower than i386 on identical AMD 64 system? Message-ID: <20060315184606.GA85629@xor.obsecurity.org> In-Reply-To: <200603150601.26135.joao@matik.com.br> References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> <200603150601.26135.joao@matik.com.br>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFEGGDuWry0BWjoQKURAvQ0AKDmeIUxRQOIYrQvCPq5sWd+sjZ6xgCg3jBN ylcqmedSgCo0uzY1K2WEW4o= =Cedt -----END PGP SIGNATURE-----home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060315184606.GA85629>