Date: Wed, 15 Mar 2006 17:28:35 -0300 From: JoaoBR <joao@matik.com.br> To: Kris Kennaway <kris@obsecurity.org> Cc: freebsd-amd64@freebsd.org Subject: Re: amd64 slower than i386 on identical AMD 64 system? Message-ID: <200603151728.35620.joao@matik.com.br> In-Reply-To: <20060315184606.GA85629@xor.obsecurity.org> References: <200603140740.38388.joao@matik.com.br> <200603150601.26135.joao@matik.com.br> <20060315184606.GA85629@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603151728.35620.joao>