# Doubts about CONFIG_NR_CPUS and MAKEOPTS options

## fturco

I have a Gentoo desktop system with an old dual-core Intel Core 2 Duo CPU:

```
$ lscpu

Architecture:        x86_64

CPU op-mode(s):      32-bit, 64-bit

Byte Order:          Little Endian

Address sizes:       36 bits physical, 48 bits virtual

CPU(s):              2

On-line CPU(s) list: 0,1

Thread(s) per core:  1

Core(s) per socket:  2

Socket(s):           1

NUMA node(s):        1

Vendor ID:           GenuineIntel

CPU family:          6

Model:               23

Model name:          Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz

Stepping:            10

CPU MHz:             2989.401

BogoMIPS:            5978.79

Virtualization:      VT-x

L1d cache:           32K

L1i cache:           32K

L2 cache:            6144K

NUMA node0 CPU(s):   0,1

Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority dtherm
```

Since my CPU is dual-core, at first I built my kernel with the CONFIG_NR_CPUS=2 option. But after booting my system I get a warning message in the logs:

```
Sep 10 12:11:11 desktop kernel: smpboot: 4 Processors exceeds NR_CPUS limit of 2
```

If I set CONFIG_NR_CPUS=4 the previous warning message disappears, but I don't understand where the number 4 comes from.

Moreover if I set both CONFIG_NR_CPUS=4 and MAKEOPTS="-j4", emerge will be slightly slower at building packages than if I stay with CONFIG_NR_CPUS=2 and MAKEOPTS="-j2".

Does anyone have an idea? What are the optimal settings for my CPU?

----------

## NeddySeagoon

fturco,

Well, Flags: includes ht, which is hyper-threading.

Is that disabled in your BIOS?

CONFIG_NR_CPUS=4 is correct with your Dual Core CPU if it really has hyper threading.

This Intel Page says no hyper threading.

CONFIG_NR_CPUS=4 costs you a few kB of waste RAM if its not real, so go with it. 

MAKEOPTS= Is not related only to your CPU.  Each MAKEOPTS thread can want 2G RAM on bigger packages.

When you run out out of RAM, one way or another, you start swapping.

How many tux logos do you get on your framebuffer boot screen?

If you get four, the kernel thinks you have four logical cores.

----------

## mike155

The Intel Core2 Duo CPU E8400 doesn't have Hyper-Threading: https://ark.intel.com/en/products/33910/Intel-Core-2-Duo-Processor-E8400-6M-Cache-3-00-GHz-1333-MHz-FSB

Which motherboard do you have?

Please post your kernel config using wgetpaste.

----------

## NeddySeagoon

mike155,

That's the page I linked too. 

I wonder if hyperthreading was added with a microcode update ?

----------

## fturco

/usr/src/linux/.config

I have an Intel DQ35JO motherboard.

I don't upgrade the microcode.

With the next reboot I'll check any reference to hyper-threading in the BIOS and the number of Tux logos on screen.

Edit #1:

I haven't found any reference to hyper-threading in the BIOS.

CONFIG_LOGO is currently disabled in my kernel. Should I enable it?

Edit #2:

Even if I enable CONFIG_LOGO in the kernel it seems I cannot display it at boot. I tried removing the "quiet" option and adding "nomodeset", to no avail.

dmesg

Edit #3:

I forgot to tell you I'm not using a Gentoo kernel. I'm using linux-libre. I'm not sure if this matters.

----------

## mike155

@NeddySeagoon: 

I'm sorry - i didn't see the link in your post.

It's quite possible that Intel added hyperthreading with a microcode update. But it's unlikely. Furthermore, Google doesn't show any articles about such an event...

@fturco: thanks for the files you posted. I don't see anything wrong in your kernel config or in dmesg.

Intel ark shows that the mainboard was released earlier than the processor. It may well be that your mainboard needs a BIOS update: https://ark.intel.com/products/50382/Intel-Desktop-Board-DQ35JO

----------

## fturco

I'll try updating the BIOS. Thanks for the suggestion.

----------

## NeddySeagoon

fturco,

Your dmesg output would be useful.

CONFIG_DRM_I915=y gets you a frambuffer console on Intel GPUs 

CONFIG_FRAMEBUFFER_CONSOLE=y says you prefer a frambuffer console if there is one.

# CONFIG_LOGO is not set says that you don't want any tux logos at boot. Its not really functional. 

Its decoration on the console and a diagnostic aid as you get one image for each detected logical core. 

linux-libre only prevents you using the in kernel firmware blobs. Some Intel GPUs need firmware some don't

If they need firmware and its not provided, missing functionality varies.

Its not an issue here.

Take care updating the BIOS. If the update fails, it can leave the system unable to boot.

This is called 'bricking' your motherboard. Recovery is non trivial.

A few systems do provision for recovery but its very ugly.

----------

## mike155

@NeddySeagoon: fturco posted his dmesg output (see Edit #2 above)

----------

## NeddySeagoon

mike155,

Thank you.

```
[    0.261938] smp: Bringing up secondary CPUs ...

[    0.261938] x86: Booting SMP configuration:

[    0.261938] .... node  #0, CPUs:      #1

[    0.262969] smp: Brought up 1 node, 2 CPUs

[    0.262969] smpboot: Max logical packages: 2

[    0.262969] smpboot: Total of 2 processors activated (11957.78 BogoMIPS)
```

and no complaints about more CPUs than the kernel can drive but it is set up for 4 CPUs

```
[    1.117779] fbcon: inteldrmfb (fb0) is primary device

[    1.273260] Console: switching to colour frame buffer device 240x75

[    1.289987] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
```

That's good.

If you turned on logos, I think you would get two. 

I recall something about Intel setting the ht flag in some CPU that were not hyperthreading capable but it was a long time ago.

----------

## fturco

The latest BIOS for my motherboard is from 2010 (!). Anyway, I already have the latest version (1143).

Edit #1: I went ahead and filed a bug upstream: https://bugzilla.kernel.org/show_bug.cgi?id=202385

Edit #2: I forgot to thank you both for the help!

----------

