From owner-freebsd-current Fri Jan 31 11:52:57 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B941C37B401 for ; Fri, 31 Jan 2003 11:52:55 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 168BB43E4A for ; Fri, 31 Jan 2003 11:52:55 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.6/8.12.6) with ESMTP id h0VJqrSJ076160; Fri, 31 Jan 2003 11:52:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.6/8.12.6/Submit) id h0VJqrMB076135; Fri, 31 Jan 2003 11:52:53 -0800 (PST) Date: Fri, 31 Jan 2003 11:52:53 -0800 (PST) From: Matthew Dillon Message-Id: <200301311952.h0VJqrMB076135@apollo.backplane.com> To: Bosko Milekic Cc: "Daniel C. Sobral" , Trish Lynch , freebsd-current@FreeBSD.ORG Subject: Re: Hyperthreading and machdep.cpu_idle_hlt References: <20030131125804.E1357-100000@femme> <200301311824.h0VIOtmF095380@apollo.backplane.com> <3E3AC33E.9060204@tcoip.com.br> <200301311908.h0VJ8cNZ007396@apollo.backplane.com> <20030131141700.A7526@unixdaemons.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message