O número principal é 0,4,8,.....39 no sensors
comando.
Por que não 0,1,2,3,4.....?
foo@foo-linux:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +73.0°C (high = +80.0°C, crit = +100.0°C)
Core 0: +46.0°C (high = +80.0°C, crit = +100.0°C)
Core 4: +50.0°C (high = +80.0°C, crit = +100.0°C)
Core 8: +52.0°C (high = +80.0°C, crit = +100.0°C)
Core 12: +47.0°C (high = +80.0°C, crit = +100.0°C)
Core 16: +73.0°C (high = +80.0°C, crit = +100.0°C)
Core 20: +50.0°C (high = +80.0°C, crit = +100.0°C)
Core 24: +58.0°C (high = +80.0°C, crit = +100.0°C)
Core 28: +52.0°C (high = +80.0°C, crit = +100.0°C)
Core 36: +48.0°C (high = +80.0°C, crit = +100.0°C)
Core 37: +48.0°C (high = +80.0°C, crit = +100.0°C)
Core 38: +48.0°C (high = +80.0°C, crit = +100.0°C)
Core 39: +48.0°C (high = +80.0°C, crit = +100.0°C)
atualizar novamente
Este é um Intel(R) Core(TM) i7-12700 de 12ª geração
Este é um PC, não um servidor, com apenas 1 soquete de CPU.
atualizar
foo@foo-linux:~$ cat /proc/cpuinfo | grep -i apicid
apicid : 0
initial apicid : 0
apicid : 1
initial apicid : 1
apicid : 8
initial apicid : 8
apicid : 9
initial apicid : 9
apicid : 16
initial apicid : 16
apicid : 17
initial apicid : 17
apicid : 24
initial apicid : 24
apicid : 25
initial apicid : 25
apicid : 32
initial apicid : 32
apicid : 33
initial apicid : 33
apicid : 40
initial apicid : 40
apicid : 41
initial apicid : 41
apicid : 48
initial apicid : 48
apicid : 49
initial apicid : 49
apicid : 56
initial apicid : 56
apicid : 57
initial apicid : 57
apicid : 72
initial apicid : 72
apicid : 74
initial apicid : 74
apicid : 76
initial apicid : 76
apicid : 78
initial apicid : 78
Esta resposta pode não surpreendê-lo, mas: porque foi assim que
sensors
foi escrito.sensors
apenas usasensors_get_detected_chips
para passar por todos os sensores existentes - não pelos núcleos da CPU. E essa ordem dos sensores é "conforme detectado" nos barramentos relevantes (portanto, principalmente I²C/SMBUS, ISA emulado), não na ordem da numeração (relativamente arbitrária) dos núcleos da CPU.O número do núcleo vem da
cpu_core_id
variável nostruct temp_data
módulocoretemp
do driver. Em seu código-fonte,cpu_core_id
está descrito assim:O
rdmsr
ewrmsr
são instruções de código de máquina para ler/gravar registradores específicos do modelo no processador especificado. Ocoretemp
módulo usa essas instruções por meio de funções definidas em arch/x86/lib/msr-smp.c . Essas funções apenas passam o campo CPU/core ID como estão, então os IDs mostrados são exatamente os IDs usados por sua placa-mãe e CPU(s).Se sua placa-mãe tiver 4 soquetes de CPU com apenas um soquete preenchido, o firmware pode ter configurado para atribuir os números de identificação a cada soquete por vez, portanto, os IDs que pertenceriam aos soquetes vazios não serão usados. Mas, no seu caso, há uma sequência de quatro IDs de núcleo contíguos no final (36 .. 39), então isso pode ser algo diferente.
Talvez este seja um único processador que possui dois tipos de núcleos, sendo que um tipo de núcleo é numerado com lacunas na numeração (0, 4, 8 ...) e o outro tipo sem lacunas (36 .. 39)?
Para saber mais, seria necessário identificar o modelo de processador exato (por exemplo, usando a saída de
lscpu | head -14
) e, em seguida, estudar a documentação técnica desse modelo de processador para ver como os IDs de núcleo são atribuídos no nível de hardware/microcódigo.Se a placa-mãe/firmware não pode ditar a atribuição de IDs de núcleo, pode-se supor que o fabricante da CPU pode estar planejando uma próxima geração de processadores com mais núcleos do primeiro tipo (ou seja, com as lacunas na numeração parcial ou totalmente preenchidas) . Mas isso é apenas um palpite, e os planos do fabricante podem mudar de qualquer maneira...