From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 09:01:49 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E86016A401 for ; Wed, 15 Mar 2006 09:01:49 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75E7A43D46 for ; Wed, 15 Mar 2006 09:01:48 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from anb (anb.matik.com.br [200.152.83.34]) by msrv.matik.com.br (8.13.4/8.13.1) with ESMTP id k2F91jv8051806; Wed, 15 Mar 2006 06:01:45 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Wed, 15 Mar 2006 06:01:25 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603141914.54442.joao@matik.com.br> <20060315022800.GA47353@xor.obsecurity.org> In-Reply-To: <20060315022800.GA47353@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200603150601.26135.joao@matik.com.br> X-Filter-Version: 1.11a (msrv.matik.com.br) X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on msrv.matik.com.br X-Virus-Status: Clean Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2006 09:01:49 -0000 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 RA= M. > > 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= =20 work > > 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 > > 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 > 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=20 resuming my experience: SMP with single dual-core processors on standard MBs are sensitive (crashi= ng=20 easily or time-outs) with non polling NICs SMP with single dual-core processors are randomly crashing when >2GB and <4= GB=20 on standard MBs Both issues are not appearing at all when changing the X2 for a standard=20 athlon 64 processor, means same hardware, same OS version and kernel Both issues are also not appearing when using the dual-core running same=20 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= =20 more than 2GB of RAM Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br