Date: Fri, 24 Jan 2003 17:25:27 -0800 From: Peter Wemm <peter@wemm.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Nate Lawson <nate@root.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Attila Nagy <bra@fsn.hu> Subject: Re: cvs commit: src/sys/i386/i386 identcpu.c initcpu.c locore.s Message-ID: <20030125012527.EE5542A89E@canning.wemm.org> In-Reply-To: <XFMail.20030124142224.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > > On 24-Jan-2003 Nate Lawson wrote: > > On Fri, 24 Jan 2003, Attila Nagy wrote: > >> Nate Lawson wrote: > >> > The patch merely enables an Auxiliary Processor on equipment that > >> > supports HTT. Thus, 4.x still has all its original SMP weaknesses that > >> > will lead people (eventually) to 5.x including the fact that only one > >> > process can be active in the kernel at a time. > >> > >> And what about performance? I mean those "Auxiliary Processors" are > >> "weaker" than the real ones, so scheduling CPU intensive processes to them > >> makes a weird assymmetry. In average for example with a dnetc client > >> what's better? :) > >> Running two processes with HT turned off, or running four of them with HT > >> on? > > > > I'm not sure what you mean by "weaker". If you have code that is > > multi-process and it runs faster on an SMP system than a single CPU > > system, then it is likely to run faster with HTT than without. Read the > > Intel pages to find more about HTT. > > Maybe. Preliminary buildworld tests on 4.x seem to suggest that HTT > is slower than UP, but buildworld is just one application. HTT will > probably be optional on stable. On -current we will eventually use > ACPI to enumerate CPU's which means that we will respect BIOS settings > with regards to whether or not HTT is enabled. Did you remember to set machdep.cpu_idle_hlt to 1? Failing to set this will really suck because the logical cores will be spinning like crazy and stealing execution resources from functional tasks on the other part of the cpu. Secondly, we just ran into a huge problem at work. I dont know how much of this is vendor specific, chipset specific or whatever, but a certain class of new machines that we have *CANNOT* run FreeBSD properly unless we apply the RELENG_4 version of htt.patch. We're still trying to figure out why this is happening but it is related to the way that we change the TPR to bias interrupts towards a cpu that has the 4.x giant lock. I have a suspicion that the logical AP's are sitting there with a left over boot-time TPR of 0 and are somehow partly participating in the apic message traffic or arbitration. Whatever the case, setting the TPR on all AP's and logical cores seems to solve the problem quite nicely. These machines have older Pentium 4 Xeons. This isn't restricted to the newer single-processor HTT Pentium 4's. So there you have it. A bunch of machines that we (so far) cannot run FreeBSD 4.x on in SMP mode without the 4.x htt.patch. Not that I'd want to cause any excitement or anything. :-) Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030125012527.EE5542A89E>