Date: Wed, 13 Sep 2006 17:12:32 -0400 (EDT) From: Kris Kennaway <kkennawa@yahoo.ca> To: Mike Meyer <mwm@mired.org>, Kris Kennaway <kris@obsecurity.org> Cc: freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... Message-ID: <20060913211232.59211.qmail@web35907.mail.mud.yahoo.com> In-Reply-To: <17672.22312.473257.577649@bhuda.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--- Mike Meyer <mwm@mired.org> wrote: > > i.e. since the hyperthreading virtual CPUs are not > actually real CPUs, > > they spend a lot of time blocked in the same CPU > core waiting for > > another hyperthread to release a resource, so the > threads are both > > "running" from the point of view of the OS, but > one is doing no work > > on the CPU a lot of the time. > > In other words, hyperthreading makes the measurement > FreeBSD takes to > see how much cpu time is being used nearly > meaningless. I hadn't > realized that. > > My understanding was that hyperthreading was > intended to let the > system make more efficient use of the CPU, by > providing two > instruction streams to be scheduled in the pipeline. > This means you > get fewer bubbles in the pipeline, resulting in more > work getting done > in the same number of cycles. The hyperthreads don't > lock resources > per se, but there are lots of screwy rules about > when things can be > put in the pipeline, leading to the same result - a > hyperthread will > "wait" some number of steps in the pipeline for the > rules to allow the > hyperthreads next step to happen. Later > implementations of > hyperthreading relax the rules, meaning you get less > waiting, or more > efficient use of the cpu, depending on how you want > to look at it. Yes, but the net result is that when two instructions are scheduled on the CPU which require the same CPU execution unit or other CPU resource, they will serialize on the chip, and from the point of view of the OS one instruction will take twice as long to execute as the other. There's nothing the OS can really do to avoid charging the process for the extra time since the OS doesn't know that the CPU blocked one of the instructions it was told to execute. Anyway, there are other conditions where the CPU will stall a "running" instruction leading to "extra" time charged to the process when the CPU was doing no work (e.g. cache misses), so this is just one more thing to understand about CPU performance and what affects it. If you really want to tune your application precisely then you need to delve into the statistics counters provided by the CPU (see e.g. pmcstat(8)). Note that you can still use the existing time accounting behaviour to tune your application for performance (or evaluate how non-optimal it is) on a HTT CPU, e.g. by comparing numbers with/without HTT. > > This means that hyperthreading may or may not > increase your > > performance depending on your workload (in your > case it does). > > Which is why I checked. This behavior isn't really > different from any > other multi-CPU system: enabling another processor > may or may not > increase your performance depending on your > workload. In particular, > if some shared resource is the critical one for your > workload and you > don't get more of it by turning on the second CPU, > turning on the > second CPU will not improve performance, and will > probably hurt it by > adding overhead. Hyperthreading is the worst case I > know of, because > those CPUs share the CPU core. Yep, not different in quality, but in degree; if you compare a dual core system to a hyperthreading system, all other things being equal a dual core system will win hands down. The key to remember is that while hyperthreading presents itself to the OS as being two independent virtual CPUs, there are worst case scenarios where it's no better than a single CPU and in practise is worse than a single CPU because of the extra overhead required in a SMP kernel. Kris __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060913211232.59211.qmail>