Date: Sat, 1 Feb 2003 10:01:20 -0500 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Peter Wemm <peter@wemm.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, "Daniel C. Sobral" <dcs@tcoip.com.br>, Trish Lynch <trish@bsdunix.net>, freebsd-current@FreeBSD.ORG Subject: Re: Hyperthreading and machdep.cpu_idle_hlt Message-ID: <20030201100120.A11945@unixdaemons.com> In-Reply-To: <20030131194817.335B72A89E@canning.wemm.org>; from peter@wemm.org on Fri, Jan 31, 2003 at 11:48:17AM -0800 References: <20030131141700.A7526@unixdaemons.com> <20030131194817.335B72A89E@canning.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 31, 2003 at 11:48:17AM -0800, Peter Wemm wrote: > The cache and most of the execution hardware is shared. The execution > units can run something like 4 instructions per clock. If the "idle" > logical core is in a spinloop, then it is generating instructions for > execution, so you are dividing the execution resources between one context > that is doing real work, and the other context that is burning off the > "excess" resources. Overall, it is a huge loss. It is absolutely essential > that logical cpus be halted when they are not doing useful work. What bothers me is that we have systems like UMA and mb_alloc (and possibly others) which have per-CPU structures, i.e., per-CPU caches, and when HTT is enabled, even the logical CPUs get their own cache when, in fact, it would probably be better (and less cache polluting) if the "logical units" (states) shared the same per-CPU structures. Briefly back to the cpu_idle_hlt story: Would it be possible to, at runtime - besides for just getting cpuid which gives us the logical unit number - get the actual physical CPU number that we're executing on? e.g., in a 2 x 4 Xeon with HTT enabled, cpuid will range from 0 to 3, would it be possible to have an equivalent variable that will give us only the physical unit number (in this case, it would range from 0 to 1, as there are two physical execution units). That way, we can count how many times we issue 'hlt' for a thread running on physical unit number N, for example, and if we have 2 logical units per physical unit for instance, then when the count hits 1 no longer do the 'hlt' to not lose a tick? The counter would have to be re-set at the next tick everytime a logical unit comes out of hlt and schedules a process. You know what I mean? It sounds a little complicated and I'm not sure it would be worth the effort, but it would get us the best of both scenarios, i.e., halt the logical unit when another logical unit on the same core is executing Real Code, and not halt the logical unit if both logical units on the given execution engine are idle. In any case, even if the above is not worth it, I'd still like to know if it's possible to get the physical unit number, as opposed to the logical unit number, at runtime? [...] > 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 -- Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030201100120.A11945>