From owner-freebsd-amd64@FreeBSD.ORG Wed Mar 15 20:29:01 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 4CC0C16A401 for ; Wed, 15 Mar 2006 20:29:01 +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 E984A43D6B for ; Wed, 15 Mar 2006 20:28:58 +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 k2FKStIn082717; Wed, 15 Mar 2006 17:28:56 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR To: Kris Kennaway Date: Wed, 15 Mar 2006 17:28:35 -0300 User-Agent: KMail/1.9.1 References: <200603140740.38388.joao@matik.com.br> <200603150601.26135.joao@matik.com.br> <20060315184606.GA85629@xor.obsecurity.org> In-Reply-To: <20060315184606.GA85629@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: <200603151728.35620.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 20:29:01 -0000 On Wednesday 15 March 2006 15:46, Kris Kennaway wrote: > > 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. > as well may exist good reason to check them out, if nobody checks this thin= gs=20 we never know about, right? preemption and ipi_preemption are good theories (seems to me) and things li= ke=20 that are worth to be tried even knowing that they are in early stage anyway I am not blaming somebody nor the OS for anything instead I tried to= =20 exchange experiences in first place. > > 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. > ok but I am not that stupid to try a prototype scheduler and then blaming i= t=20 for my mess > > 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. > well, that was my first thought too but makes no sense if the same happens = on=20 several different brands, anyway I checked and tested different bios versio= ns=20 on any board because the thing is important to me, I can not migrate 500=20 servers having this problem=20 also it is clearly X2 processor related since it doesn't appear when using = a=20 normal athlon64, then you may say ACPI is to blame what could be the case o= f=20 Asus or Abit but the EPOX ACPI is very clean and appearently error free My guess here is the shared memory access when running X2-SMP=20 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