Project Home
Project Home		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
QNX Operating System/Discussion/OSTech/x86 hyperthreading/List of Posts
Forum Topic - x86 hyperthreading: (10 Items)
   
Update
Mario Charest
09/23/2010 1:34 PM
post68407
x86 hyperthreading   
With 6.5.0 I tested the effect of enabling hyper-threading on performance and it's bad.  Seems the kernel doesn't know 
that the extra CPU aren't real.

My testing shows that CPU 0-1 are the same, CPU 2-3 and so on. If I start a process with two threads, it's not much 
faster then having one thread only as the two threads are allocated to CPU0 (real) and CPU1 ( hyperthreading). If I 
start the program with
on -C0 and -C2 then I get the performance I expect.

Is there any option or way aside using "on" all over the place to make the kernel smarter about its cpu allocation?
Attilla Danko(deleted)
09/23/2010 1:38 PM
post68409
RE: x86 hyperthreading   
All the code i've seen indicates the kernel assumes all cpus are equivalent.

-----Original Message-----
From: Mario Charest [mailto:community-noreply@qnx.com]
Sent: Thu 2010-09-23 13:34
To: ostech-core_os
Subject: x86 hyperthreading
 
With 6.5.0 I tested the effect of enabling hyper-threading on performance and it's bad.  Seems the kernel doesn't know 
that the extra CPU aren't real.

My testing shows that CPU 0-1 are the same, CPU 2-3 and so on. If I start a process with two threads, it's not much 
faster then having one thread only as the two threads are allocated to CPU0 (real) and CPU1 ( hyperthreading). If I 
start the program with
on -C0 and -C2 then I get the performance I expect.

Is there any option or way aside using "on" all over the place to make the kernel smarter about its cpu allocation?





_______________________________________________

OSTech
http://community.qnx.com/sf/go/post68407
Attachment: Text winmail.dat 2.74 KB
Mario Charest
09/23/2010 1:45 PM
post68410
RE: x86 hyperthreading   

> -----Message d'origine-----
> De : Attilla Danko [mailto:community-noreply@qnx.com]
> Envoyé : 23 septembre 2010 13:38
> À : ostech-core_os
> Objet : RE: x86 hyperthreading
> 
> 
> All the code i've seen indicates the kernel assumes all cpus are equivalent.

Thanks. Basically that means QNX6 doesn't really "support" hyper-threading on x86.

For some reason my selective memory remember that : 

http://www.embeddedstar.com/press/content/2002/9/embedded5049.html

Cheers!

> 
> -----Original Message-----
> From: Mario Charest [mailto:community-noreply@qnx.com]
> Sent: Thu 2010-09-23 13:34
> To: ostech-core_os
> Subject: x86 hyperthreading
> 
> With 6.5.0 I tested the effect of enabling hyper-threading on performance
> and it's bad.  Seems the kernel doesn't know that the extra CPU aren't real.
> 
> My testing shows that CPU 0-1 are the same, CPU 2-3 and so on. If I start a
> process with two threads, it's not much faster then having one thread only as
> the two threads are allocated to CPU0 (real) and CPU1 ( hyperthreading). If I
> start the program with on -C0 and -C2 then I get the performance I expect.
> 
> Is there any option or way aside using "on" all over the place to make the
> kernel smarter about its cpu allocation?
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post68407
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post68409
Dennis Kellly
09/23/2010 1:46 PM
post68411
Re: RE: x86 hyperthreading   
 >>>All the code i've seen indicates the kernel assumes all cpus are equivalent.

Maybe that's because its called "symmetric" multiprocessing :)
Oleh Derevenko(deleted)
09/23/2010 1:48 PM
post68412
Re: x86 hyperthreading   
If the calculations can be split into multiple threads it's usually a good practice to start from as much to twice as 
much threads as there are CPUs in the system. And this automatically solves your problem.

> My testing shows that CPU 0-1 are the same, CPU 2-3 and so on. If I start a 
> process with two threads, it's not much faster then having one thread only as 
> the two threads are allocated to CPU0 (real) and CPU1 ( hyperthreading). If I 
> start the program with
> on -C0 and -C2 then I get the performance I expect.
Mario Charest
09/23/2010 1:59 PM
post68414
RE: x86 hyperthreading   

> -----Message d'origine-----
> De : Oleh Derevenko [mailto:community-noreply@qnx.com]
> Envoyé : 23 septembre 2010 13:49
> À : ostech-core_os
> Objet : Re: x86 hyperthreading
> 
> If the calculations can be split into multiple threads it's usually a good practice
> to start from as much to twice as much threads as there are CPUs in the
> system. And this automatically solves your problem.

Huh?  Say I run a program at priority 10 with 16 threads ( on an 4 core + 4 thread).  Then network stuff is happening at
 priority 20, but io-pkt and its threads end up being assigned to core 1-3-5, what will happen is that io-pkt could run 
a 5% of the speed it's supposed to.  Not good.

> 
> > My testing shows that CPU 0-1 are the same, CPU 2-3 and so on. If I
> > start a process with two threads, it's not much faster then having one
> > thread only as the two threads are allocated to CPU0 (real) and CPU1 (
> > hyperthreading). If I start the program with on -C0 and -C2 then I get
> > the performance I expect.
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post68412
>
Oleh Derevenko(deleted)
09/24/2010 5:34 AM
post68473
Re: RE: x86 hyperthreading   
> > If the calculations can be split into multiple threads it's usually a good 
> practice
> > to start from as much to twice as much threads as there are CPUs in the
> > system. And this automatically solves your problem.
> 
> Huh?  Say I run a program at priority 10 with 16 threads ( on an 4 core + 4 
> thread).  Then network stuff is happening at priority 20, but io-pkt and its 
> threads end up being assigned to core 1-3-5, what will happen is that io-pkt 
> could run a 5% of the speed it's supposed to.  Not good.
> 
Execution is preempted and execution time is assigned to threads in small time slices. That's why it does not have any 
effect if once you'll have an unfortunate combination - the next time slice the threads could be assigned to completely 
different cores. In general everything will be fine unless you explicitly bind your threads to bad core combination.
Mario Charest
09/24/2010 8:33 AM
post68488
RE: RE: x86 hyperthreading   

> -----Message d'origine-----
> De : Oleh Derevenko [mailto:community-noreply@qnx.com]
> Envoyé : 24 septembre 2010 05:34
> À : ostech-core_os
> Objet : Re: RE: x86 hyperthreading
> 
> > > If the calculations can be split into multiple threads it's usually
> > > a good
> > practice
> > > to start from as much to twice as much threads as there are CPUs in
> > > the system. And this automatically solves your problem.
> >
> > Huh?  Say I run a program at priority 10 with 16 threads ( on an 4
> > core + 4 thread).  Then network stuff is happening at priority 20, but
> > io-pkt and its threads end up being assigned to core 1-3-5, what will
> > happen is that io-pkt could run a 5% of the speed it's supposed to.  Not
> good.
> >
> Execution is preempted and execution time is assigned to threads in small
> time slices. That's why it does not have any effect if once you'll have an
> unfortunate combination -

Have you actally done this in real life scenario or your just theorising? What you are saying doesn't make any sense to 
me.  Our machine has 8 core + hyperthreading thus 16 "core". Unless every  single operation  can be splited into 16 
threads to keep everything busy, real-time goes out the window, big time.

> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post68473
>
Oleh Derevenko(deleted)
09/24/2010 9:21 AM
post68503
Re: RE: RE: x86 hyperthreading   
> > Execution is preempted and execution time is assigned to threads in small
> > time slices. That's why it does not have any effect if once you'll have an
> > unfortunate combination -
> 
> Have you actally done this in real life scenario or your just theorising? What
>  you are saying doesn't make any sense to me.  Our machine has 8 core + 
> hyperthreading thus 16 "core". Unless every  single operation  can be splited 
> into 16 threads to keep everything busy, real-time goes out the window, big 
> time.

Nobody was saying it is an easy thing to keep 16 cores busy with just a single application. In any case, if you can't 
upgrade your hardware to fully independent cores you have to be prepared that a low priority thread while being 
scheduled at the same CPU in hyperthreading mode with your high priority thread will make the latter execute slower. So,
 hyperthreading is not a realtime anyway.
Mario Charest
09/24/2010 9:58 AM
post68516
RE: RE: RE: x86 hyperthreading   

> -----Message d'origine-----
> De : Oleh Derevenko [mailto:community-noreply@qnx.com]
> Envoyé : 24 septembre 2010 09:22
> À : ostech-core_os
> Objet : Re: RE: RE: x86 hyperthreading
> 
> > > Execution is preempted and execution time is assigned to threads in
> > > small time slices. That's why it does not have any effect if once
> > > you'll have an unfortunate combination -
> >
> > Have you actally done this in real life scenario or your just
> > theorising? What  you are saying doesn't make any sense to me.  Our
> > machine has 8 core + hyperthreading thus 16 "core". Unless every
> > single operation  can be splited into 16 threads to keep everything
> > busy, real-time goes out the window, big time.
> 
> Nobody was saying it is an easy thing to keep 16 cores busy with just a single
> application. In any case, if you can't upgrade your hardware to fully
> independent cores you have to be prepared that a low priority thread while
> being scheduled at the same CPU in hyperthreading mode with your high
> priority thread will make the latter execute slower. So, hyperthreading is not
> a realtime anyway.

It could if the kernel had a concept of core speed and prioritized them ;-) 

My solution for now, turn hyperthreading off in the BIOS.   Plain in simple !


> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post68503
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems