Date: Fri, 31 Jan 2003 11:52:53 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bosko Milekic <bmilekic@unixdaemons.com> Cc: "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: <200301311952.h0VJqrMB076135@apollo.backplane.com> References: <20030131125804.E1357-100000@femme> <200301311824.h0VIOtmF095380@apollo.backplane.com> <3E3AC33E.9060204@tcoip.com.br> <200301311908.h0VJ8cNZ007396@apollo.backplane.com> <20030131141700.A7526@unixdaemons.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: Why do you think that hlt-ing the CPU(s) when idle would actually
: improve performance in this case? My only suspicion is that perhaps
: this reduces scheduling on the auxiliary 'logical' (fake) CPUs,
: thereby indirectly reducing cache ping-ponging and abuse. I would
: imagine that both units sharing the same execution engine in the
: HTT-enabled model would be effectively 'hlt'-ed when one of the two
: threads executes an 'hlt' until the next timer tick.
:
: I guess we'll wait for the two other data sets from Trish: one with
: HTT off, and cpu_idle_hlt=0, and the other with HTT off, and
: cpu_idle_hlt=1, before figuring this out.
:
:--
:Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org
I am almost certain that it is related to pipeline stalls created
by the fairly long (in instructions) idle loop and the locked bus
cycles used by the mutex code. It could also possibly be related to
L1 cache contention.
I think that if we can fit the idle loop for the 'logical' processor
into a single instruction cache line and a single data cache line,
accessing a single memory location without any locked bus cycles, that
it would solve the problem. Unfortunately I have no boxes I can do
testing on so this is just a guess.
Another solution would be to have a global mask of 'idle' cpus and send
an IPI to them when a new KSE is scheduled on a non-idle cpu that would
simply serve to wakeup the HLT. IPIs are nasty, but there are large
(power consumption) advantages to standardizing on the HLT methodology.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?200301311952.h0VJqrMB076135>