# Kernel SMP scheduler and hyperthreading

## CaptainBlood

There is no BIOS setting to tweak CPU SMP scheduling or hyperthreading activation.

System works multicored and hyperthreaded.

Wondering

If kernel smp scheduling and hyperthreading should be expected to work?

If kernel smp scheduling and hyperthreading could somehow beneficial? (maybe regarding emerge maintenance process?  :Wink:  )

Thks 4 ur attention.Last edited by CaptainBlood on Fri Sep 11, 2015 4:02 am; edited 1 time in total

----------

## eccerr0r

??? Error: Post does not grok.

If SMP is supported by the kernel and the system (ACPI required for newer machines, else MPS for older ones) it will work.  Kernel will choose which threads to run on which cpu resource automatically...

I have a dual core dual thread CPU on this machine I'm using right now (laptop, not my i7).  There are 4 threads that the CPU package can deal with at any one time without saving state to RAM.  There are kernel options to make sure the OS does the right things with each of the threads instead of blindly selecting threads to run on each hardware thread, such as trying to group related software to the same package (if you have more than one processor socket), however don't run two unrelated applications on the same core as different threads of that particular core.

----------

## kernelOfTruth

if you want full support for SMT + HT threading,

try BFS scheduler with SMTNICE set

otherwise there are some changes related to SMP for 4.3 kernel - but according to the mailing list (a few releases back) it still doesn't make full use of the potential of SMP & HT,

performance penalty, threads (core) bouncing and more ensues

----------

## CaptainBlood

Tried each and combined,

Not really convinced via a 4 mn emerge timings, keeping though.

----------

## eccerr0r

what do you mean by a "4mn emerge timings" ?  Expect it to be faster?

What hardware?

How many cores detected in /proc/cpuinfo ?

How many jobs during make?

What package are you building - some are forced to not be parallelized (they're getting fewer in number) and thus will not benefit much from SMP/HT.

----------

## CaptainBlood

Gosh, my previous reply got lost in the void ...

I meant I only mesured timing building an average  4 mn ebuild with hardware smp on gentoo-sources, software from gentoo-source and ck-sources, all at 4.0.9 (despite it is not in the tree anymore, I have to keep it for wifi compatibility with an out of the kernel driver that doesn't work with upper kernel version).

ftlo=4, graphite and openmp are default.

gcc and kernel are not stack protected,

kernel is in "server" mode

var/tmp is tmpfs

gcc is latest x64 stable.

Can't remember which ebuild I picked though ...

I'm may have done things the wrong way, but compilation timing didn't show any significant avantage for sw smp multithreading of my poor i3 2 core/4 threads.

Thanks for your attention, interest and support.

----------

## eccerr0r

Are you using "make -j X" to build your kernel where X is the number of cores you have plus 1?

Running 'top' in another window to ensure more than one gcc is running?

If you meant 4 minutes to compile a kernel, that sounds about right when you're using all cores on a fast machine.

The HT virtual threads will not give much of an improvement over real cores, but should give you 10% or so depending on your situation.

What do you mean by "SW SMP"?

You can't really "disable" HT in your kernel config, HT needs to be disabled in firmware/BIOS.  The kernel option merely makes sure you use two real cores instead of dumping everything on the same core on different threads.  If you keep your make jobs loaded with 4 jobs, it will not make a difference because all threads would be utilized anyway.  It's the case where when you only have two jobs and two real cores plus two virtual cores that a "stupid" scheduler may make the wrong choice.

----------

## CaptainBlood

CONFIG_SCHED_SMT TRUE

CONFIG_SCHED_MC TRUE <=What do you mean by "SW SMP"

CONFIG_PREEMPT_TRUE

Because of multithread (whether hard of soft managed) CONFIG_NR_CPUS is set to 4.

Please let me know if that's silly;

As for kernel "make -j4 -l4" on dual core multithreaded, so no +1.

The 4 mn is not related to kernel make ...

Pending answer ...

----------

## eccerr0r

An answer can never come to a question that wasn't asked... or at least to one that wasn't clear...

If you see 4 processors in /proc/cpuinfo and you have make -j4 -l4 then Linux should be taking advantage of all 4 threads.

You may or may not see all 4 threads being used at any one time in 'top' because they may finish before top registers them.  But when compiling C++ programs that take a while, you should see all 4 threads being used.

As long as you're seeing at least 2 threads used 100% and you have CONFIG_SCHED_SMT set to TRUE then you should be taking full advantage of your computer.

CONFIG_SCHED_MC is used for machines that have more than one chip (versus multiple cores on one cpu package) on your motherboard, which you do not (actually it's a bit more complicated than this, but this simplifies things).  Having it enabled won't affect your machine as much as the CONFIG_SCHED_SMT does.

----------

## CaptainBlood

At least CONFIG_SCHED_MC is being set back to "N" everywhere ...

----------

## krinn

But remember HT cores are not real core, but use real core to handle a thread and use that core resource to do it ; it means under some conditions the HT/core cannot run the thread because the real/core it depends on is busy and its resource cannot be use.

Dig HT docs/wiki/infos to see what they shared.

So when you assume a 2 core HT cpu is 4 full threads, you assume it will never fails and the HT cores will always be able to work.

Alas a 2 cores HT cpu is not a 4 cores non HT cpu equivalent, and the 4 cores cpu will always win.

----------

