Date: Fri, 24 Jan 2003 14:22:24 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Nate Lawson <nate@root.org> Cc: 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: <XFMail.20030124142224.jhb@FreeBSD.org> In-Reply-To: <Pine.BSF.4.21.0301241018340.75548-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.20030124142224.jhb>