Date: Thu, 14 Sep 2006 13:39:18 -0400 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Gary Corcoran <gcorcoran@rcn.com> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, freebsd-hackers@freebsd.org Subject: Re: numbers don't lie ... Message-ID: <17673.37830.1883.272019@bhuda.mired.org> In-Reply-To: <45099123.4000500@rcn.com> References: <E1GNOLq-000DC2-1Q@cs1.cs.huji.ac.il> <863bauk3gp.fsf@dwp.des.no> <45099123.4000500@rcn.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In <45099123.4000500@rcn.com>, Gary Corcoran <gcorcoran@rcn.com> typed: > The confusing thing is that I thought 'real' time should be >= 'user' + 'sys'. > But here 'user' is much greater than 'real' for both machines! The sense I > got from the other messages in this thread is that 'user' time is somewhat > meaningless (i.e. unreliable as a measure) in a multi-CPU and/or hyperthreading > environment. Can you clarify? 'real' is wall clock time. 'user' and 'sys' are cpu time. If your process gets all of some cpu, then user + sys will be the same as real time. It's not possible to get more than all of a cpu, so that's a maximum *per cpu*. If you have multiple cpus, the formula you want is 'real' * ncpu >= 'user' + 'sys'. I made the comment about freebsd's measure of user time being skewed by hyperthreading. That's a bit vague. The problem is that waiting caused by hyperthreading will count against the instruction that's doing the waiting, which skews them. But as Kris pointed out, there are other things that have that property, so this is just one more complication when it comes to figuring the performance of modern CPUs. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17673.37830.1883.272019>