You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@trafodion.apache.org by Gunnar Tapper <ta...@gmail.com> on 2016/02/06 00:21:54 UTC

Hyperthreading

I'm noticing a check for hyper threading in the Trafodion scanner but it's
a warning. What's the concern?

-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

Re: Hyperthreading

Posted by Gunnar Tapper <ta...@gmail.com>.
I believe that this check is in the "doesn't work" category and should,
therefore, be removed as part of an overall review of the scanner
configuration...

On Wed, Feb 10, 2016 at 4:00 PM, D. Markt <dm...@gmail.com> wrote:

> Hi,
>
>
>
>   I believe years ago when testing the precursor product to Trafodion,
> which included components not currently part of Trafodion, testing with
> Hyperthreading on encountered unexpected/different from HT off results (I’m
> not sure exactly what was encountered).  Given how long ago that was, both
> HT and that product on Linux were immature and it could have been a bug at
> any level of the stack or maybe the results were just misinterpreted and
> there were other issues to resolve that using HT for that product was not a
> priority.
>
>
>
>   That’s right, not everyone, especially when HT was introduced, believed
> (or even today believes) using HT is the right thing to do.  Even the Intel
> web page (
> http://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html)
> says “Performance will vary depending on the specific hardware and
> software used. ”  Other web pages imply there can be performance loss but
> those pages tend to be older.  Some point out how it can be harder to
> interpret CPU utilization given many tools will see 2x the number of actual
> cores even though there is not actually twice the processing power per se.
>
>
>
>   With all that said, I have been involved with testing Trafodion on
> systems with and without HT enabled using several different benchmarks and
> Trafodion runs fine in both environments.  Given the Region Server is often
> one of the heaviest users of the CPU and is multi-threaded all the
> benchmark results I can recall at the moment were helped by having HT on
> save for one.  It was a variant of one of the benchmarks and the drop was
> significant enough with HT on that it wasn’t run variance.  There was one
> other test result where HT on was slightly less than with HT off but it
> could have been run variance.
>
>
>
>   So what type of a warning is the Trafodion scanner producing?  If it’s
> indicating the product might not run successfully/correctly then I think
> there has been sufficient testing to this point to remove the warning.  All
> software products either contain bugs or new bugs can be introduced with
> any change in software or hardware, including the HT support in Linux, but
> I’m not aware of any existing bug report that would preclude turning HT on
> while using Trafodion on that system.
>
>
>
>   If the warning implies there could be performance considerations
> involved when using HT then I think that will always be a valid concern,
> though maybe it should be more informational than a warning.  Very few
> performance optimizations, of which HT is an example, improve performance
> in every possible case.  Without knowing how the user’s application will
> use the system there’s no way to know if turning HT on will help
> significantly, provide a modest boost in performance, or perhaps be a minor
> detriment to system performance.  One could argue the same for how much
> memory is installed on each node, how many and how the disk drives are
> configured, etc.  So if this is a performance warning then likely it should
> be removed.
>
>
>
> Dennis
>
> *From:* Gunnar Tapper [mailto:tapper.gunnar@gmail.com]
> *Sent:* Friday, February 05, 2016 5:22 PM
> *To:* user@trafodion.incubator.apache.org
> *Subject:* Hyperthreading
>
>
>
> I'm noticing a check for hyper threading in the Trafodion scanner but it's
> a warning. What's the concern?
>
>
>
> --
>
> Thanks,
>
>
>
> Gunnar
>
> *If you think you can you can, if you think you can't you're right.*
>



-- 
Thanks,

Gunnar
*If you think you can you can, if you think you can't you're right.*

RE: Hyperthreading

Posted by "D. Markt" <dm...@gmail.com>.
Hi,

 

  I believe years ago when testing the precursor product to Trafodion, which included components not currently part of Trafodion, testing with Hyperthreading on encountered unexpected/different from HT off results (I’m not sure exactly what was encountered).  Given how long ago that was, both HT and that product on Linux were immature and it could have been a bug at any level of the stack or maybe the results were just misinterpreted and there were other issues to resolve that using HT for that product was not a priority.

 

  That’s right, not everyone, especially when HT was introduced, believed (or even today believes) using HT is the right thing to do.  Even the Intel web page (http://www.intel.com/content/www/us/en/architecture-and-technology/hyper-threading/hyper-threading-technology.html) says “Performance will vary depending on the specific hardware and software used. ”  Other web pages imply there can be performance loss but those pages tend to be older.  Some point out how it can be harder to interpret CPU utilization given many tools will see 2x the number of actual cores even though there is not actually twice the processing power per se.

 

  With all that said, I have been involved with testing Trafodion on systems with and without HT enabled using several different benchmarks and Trafodion runs fine in both environments.  Given the Region Server is often one of the heaviest users of the CPU and is multi-threaded all the benchmark results I can recall at the moment were helped by having HT on save for one.  It was a variant of one of the benchmarks and the drop was significant enough with HT on that it wasn’t run variance.  There was one other test result where HT on was slightly less than with HT off but it could have been run variance.

 

  So what type of a warning is the Trafodion scanner producing?  If it’s indicating the product might not run successfully/correctly then I think there has been sufficient testing to this point to remove the warning.  All software products either contain bugs or new bugs can be introduced with any change in software or hardware, including the HT support in Linux, but I’m not aware of any existing bug report that would preclude turning HT on while using Trafodion on that system.

 

  If the warning implies there could be performance considerations involved when using HT then I think that will always be a valid concern, though maybe it should be more informational than a warning.  Very few performance optimizations, of which HT is an example, improve performance in every possible case.  Without knowing how the user’s application will use the system there’s no way to know if turning HT on will help significantly, provide a modest boost in performance, or perhaps be a minor detriment to system performance.  One could argue the same for how much memory is installed on each node, how many and how the disk drives are configured, etc.  So if this is a performance warning then likely it should be removed.

 

Dennis

From: Gunnar Tapper [mailto:tapper.gunnar@gmail.com] 
Sent: Friday, February 05, 2016 5:22 PM
To: user@trafodion.incubator.apache.org
Subject: Hyperthreading

 

I'm noticing a check for hyper threading in the Trafodion scanner but it's a warning. What's the concern?


 

-- 

Thanks,

 

Gunnar

If you think you can you can, if you think you can't you're right.