Bug 44337 - Не определено значение MAXCPU для платформы x86_64
Summary: Не определено значение MAXCPU для платформы x86_64
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: rpm-build-vm-run (show other bugs)
Version: unstable
Hardware: x86_64 Linux
: P5 normal
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-11-17 13:55 MSK by Николай Костригин
Modified: 2022-11-21 11:12 MSK (History)
1 user (show)

See Also:


Attachments
предлагаемое исправление (871 bytes, patch)
2022-11-17 13:59 MSK, Николай Костригин
no flags Details | Diff
исправление сборки с gcc10 при бэкпорте в p10 (1.01 KB, patch)
2022-11-18 15:39 MSK, Николай Костригин
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Николай Костригин 2022-11-17 13:55:33 MSK
Падают тесты при сборке ядра в hasher на машине с 256 логическими ядрами из-за превышения количеством ядер передельного значения в 255 штук.

Задание --nprocs в параметрах hasher на это значение не влияет.


+ time qemu-system-x86_64 -M accel=tcg -m 250428M -smp cores=256 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=/dev/root -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-std-def-buildroot/boot/vmlinuz-5.10.153-std-def-alt1 -initrd /usr/src/tmp/initramfs-5.10.153-std-def-alt1.img -sandbox on,spawn=deny -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr  panic=-1 SCRIPT=/usr/src/tmp/tmp.cPZpHdjOtb NOTTY no_timer_check'

**qemu-system-x86_64: Invalid SMP CPUs 256. The max CPUs supported by machine 'pc-i440fx-6.2' is 255**

Command exited with non-zero status 1
0.01user 0.02system 0:00.03elapsed 97%CPU (0avgtext+0avgdata 27064maxresident)k
0inputs+0outputs (0major+2052minor)pagefaults 0swaps
error: Bad exit status from /usr/src/tmp/rpm-tmp.43032 (%check)
Comment 1 Николай Костригин 2022-11-17 13:59:37 MSK
Created attachment 11880 [details]
предлагаемое исправление

могу собрать исправленную версию в Сизиф, если нет возражений
Comment 2 Vitaly Chikunov 2022-11-17 14:12:02 MSK
"6.2" это значит qemu не из Сизифа? Не могли бы вы проверить что в Сизифе 256 тоже дает ошибку? 

Мне кажется, что мы уде что-то где-то исправляли на эту тему, но не нашел где и что.

> могу собрать исправленную версию в Сизиф, если нет возражений

Нету. 

TODO: Может потом придумаем как это исправить лучше. И думаю --nprocs должно поддерживаться.
Comment 3 Николай Костригин 2022-11-17 14:36:28 MSK
(Ответ для Vitaly Chikunov на комментарий #2)
> "6.2" это значит qemu не из Сизифа? Не могли бы вы проверить что в Сизифе
> 256 тоже дает ошибку? 
> 
> Мне кажется, что мы уде что-то где-то исправляли на эту тему, но не нашел
> где и что.
> 
> > могу собрать исправленную версию в Сизиф, если нет возражений
> 
> Нету. 
> 
> TODO: Может потом придумаем как это исправить лучше. И думаю --nprocs должно
> поддерживаться.

Мне тоже кажется, что умолчание в vm-run должно переопределяться внешним заданным --nprocs, т.к. пользователь ожидает этого поведения
Comment 4 Николай Костригин 2022-11-17 18:07:36 MSK
Пока не стал собирать пакет:
может быть, все таки починить более кардинально?
Пока тестируемое ядро Linux калибрует задержку для всех ядер процессора успевает выстрелить таймаут.
Или просто задерем значение таймаута? Каких-то 7 ядер не успели откалибровать.


[   36.090884]  #245
[    0.000000] calibrate_delay_direct() dropping max bogoMips estimate 0 = 72277125
[    0.000000] calibrate_delay_direct() dropping min bogoMips estimate 2 = 45102819
[    0.000000] calibrate_delay_direct() dropping max bogoMips estimate 4 = 59594272
[   36.271485]  #246
[    0.000000] calibrate_delay_direct() dropping max bogoMips estimate 3 = 61494541
[    0.000000] calibrate_delay_direct() dropping min bogoMips estimate 4 = 28948026
[   36.438659]  #247
[    0.000000] calibrate_delay_direct() dropping max bogoMips estimate 1 = 63350304
[    0.000000] calibrate_delay_direct() dropping min bogoMips estimate 0 = 41171103
[   36.654829]  #248
[    0.000000] calibrate_delay_direct() dropping min bogoMips estimate 4 = 33144271
[    0.000000] calibrate_delay_direct() dropping min bogoMips estimate 0 = 46793985
qemu-system-x86_64: terminating on signal 15 from pid 3987491 (timeout)
/usr/bin/vm-run: line 442: 3987559 Terminated              ( if grep -sq systemd-coredump /proc/sys/kernel/core_pattern; then
    ulimit -c unlimited;
else
    VM_RUN_LIBSEGFAULT=$(set +f; echo /usr/lib*/libSegFault.so); if [ -f "$VM_RUN_LIBSEGFAULT" ]; then
        LD_PRELOAD=${LD_PRELOAD:+${LD_PRELOAD}:}$VM_RUN_LIBSEGFAULT; SEGFAULT_USE_ALTSTACK=1; export LD_PRELOAD SEGFAULT_USE_ALTSTACK;
    fi;
fi; test "$NOCMD" || set -x; $TIME $QEMU $DEF -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-$VIRTIOBUS,fsdev=root,mount_tag=/dev/root -device virtio-rng-$VIRTIOBUS -serial mon:stdio -kernel $KERNEL -initrd $INITRD $OPTS -append "console=$CONSOLE mitigations=off nokaslr $QUIET panic=-1 SCRIPT=$SCRIPT$APPEND" )
error: Bad exit status from /usr/src/tmp/rpm-tmp.75441 (%check)
Comment 5 Vitaly Chikunov 2022-11-17 18:13:14 MSK
А что это за пакет таймаутит?
Comment 6 Vitaly Chikunov 2022-11-17 18:27:26 MSK
(In reply to Vitaly Chikunov from comment #5)
> А что это за пакет таймаутит?

Если std/un-def ядро, то там же таймаут 300 и 999 секунд. (А во втором случае еще надо время чтоб прогнать все тесты.) Неужто ядро грузится больше 300 секунд?
Comment 7 Vitaly Chikunov 2022-11-17 18:29:41 MSK
(In reply to Vitaly Chikunov from comment #6)
> Неужто ядро грузится больше 300 секунд?

Если да, то это не связанная проблема. И вам надо или пропускать %check или придумывать решение, может есть какие-то опции чтоб ускорить загрузку с 255 cpu. Есть ли лог?
Comment 8 Николай Костригин 2022-11-17 18:38:10 MSK
(Ответ для Vitaly Chikunov на комментарий #7)
> (In reply to Vitaly Chikunov from comment #6)
> > Неужто ядро грузится больше 300 секунд?
> 
> [...]

Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и, соответственно, отсутствие аппаратной виртуализации - поэтому так долго.
Если существуют сценарии такого использования, то таймаут маловат. Если не существует, то после проброса должно заработать. Проверю.
Comment 9 Vitaly Chikunov 2022-11-17 18:41:28 MSK
Одно из решений, но видимо не оптимальное - добавить в append lpj=

	lpj=n		[KNL]
			Sets loops_per_jiffy to given constant, thus avoiding
			time-consuming boot-time autodetection (up to 250 ms per
			CPU). 0 enables autodetection (default). To determine
			the correct value for your kernel, boot with normal
			autodetection and see what value is printed. Note that
			on SMP systems the preset will be applied to all CPUs,
			which is likely to cause problems if your CPUs need
			significantly divergent settings. An incorrect value
			will cause delays in the kernel to be wrong, leading to
			unpredictable I/O errors and other breakage. Although
			unlikely, in the extreme case this might damage your
			hardware.

Но требует 1 загрузки, чтоб узнать правильное значение (то есть не универсально и нельзя выставить заранее) и при неправильном значении может приводить к ошибкам в работе ядра.
Comment 10 Vitaly Chikunov 2022-11-17 18:43:53 MSK
(In reply to Николай Костригин from comment #8)
> Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и,
> соответственно, отсутствие аппаратной виртуализации - поэтому так долго.

То есть это 1й тест на полной эмуляции с таймаутом 300.

  timeout 300 vm-run uname -a
Comment 11 Vitaly Chikunov 2022-11-17 18:44:48 MSK
(In reply to Vitaly Chikunov from comment #10)
> (In reply to Николай Костригин from comment #8)
> > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и,
> > соответственно, отсутствие аппаратной виртуализации - поэтому так долго.
> 
> То есть это 1й тест на полной эмуляции с таймаутом 300.
> 
>   timeout 300 vm-run uname -a

Тогда было ошибкой делать такое же число cpu как в host системе!
Comment 12 Николай Костригин 2022-11-17 18:54:41 MSK
(Ответ для Николай Костригин на комментарий #8)
> > [...]
> 
> Скорее всего виновато отстутствие проброса /dev/kvm в хэшер
> [...]
> Проверю.

Все так и есть. C /dev/kvm собирается нормально и проходит тесты.
task #310175: try #1 is AWAITING
Comment 13 Vitaly Chikunov 2022-11-17 19:05:51 MSK
(In reply to Николай Костригин from comment #12)
> (Ответ для Николай Костригин на комментарий #8)
> > > [...]
> > 
> > Скорее всего виновато отстутствие проброса /dev/kvm в хэшер
> > [...]
> > Проверю.
> 
> Все так и есть. C /dev/kvm собирается нормально и проходит тесты.
> task #310175: try #1 is AWAITING

Ок я потом сделаю - если точно нет kvm то maxcpu, скажем, 4.
Comment 14 Vitaly Chikunov 2022-11-17 23:59:15 MSK
(In reply to Vitaly Chikunov from comment #2)
> И думаю --nprocs должно поддерживаться.

Понял почему не работает, опечатка.

  [ -v NPROC ] || NPROC=$(nproc)
Comment 15 Vitaly Chikunov 2022-11-18 01:39:03 MSK
Сделал тестовое задание
https://git.altlinux.org/tasks/310189/
- vm-run: Define MAXCPU=255 for x86_64
- пофикшена поддержка NPROCS
- при отсутствии KVM ограничивает MAXCPU=4
- Экспериментально, --cpu= устанавливает любое кол-во ядер, которое запросил пользователь, то есть эта опция для экспериментов в hsh-shell "что будет если столько-то ядер", а не для спеков/продакшена.
Comment 16 Vitaly Chikunov 2022-11-18 01:45:22 MSK
Кстати, у меня без KVM (-M accel=tcg -smp cores=255) 255 ядер грузится всего за ~25 секунд.

[    4.406779] smp: Bringing up secondary CPUs ...
[    4.411196] x86: Booting SMP configuration:
...
[   26.284550] smp: Brought up 1 node, 255 CPUs
Comment 17 Repository Robot 2022-11-18 07:00:30 MSK
rpm-build-vm-1.37-alt3 -> sisyphus:

 Thu Nov 17 2022 Nikolai Kostrigin <nickel@altlinux> 1.37-alt3
 - vm-run: Define MAXCPU=255 for x86_64 (closes: #44337).
Comment 18 Николай Костригин 2022-11-18 15:37:44 MSK
(Ответ для Vitaly Chikunov на комментарий #15)
> Сделал тестовое задание
> https://git.altlinux.org/tasks/310189/
> [...]

Из-за того, что мое задание уже провалилось в Сизиф придется немного переделать.
Плюс, хотелось бы видеть эти изменения в p10, но бэкпорту мешает поломка сборки с gcc10.
Патчик прилагаю.

С предложенными изменениями потестировал.
С аппаратной виртуализацией отрабатывают оба теста секции check с 255 ядрами.
Без аппаратной - тоже (калибровка пропускается, выбрано 4 ядра, запускается только 1й тест):

[...]
[    9.249991] Calibrating delay loop (skipped), value calculated using timer frequency.. 4899.99 BogoMIPS (lpj=2449998)
[    9.251060] pid_max: default: 32768 minimum: 301
[    9.252136] LSM: Security Framework initializing
[    9.253065] Yama: becoming mindful.
[    9.254079] AltHa disabled.
[    9.254642] Kiosk: Netlink family registered.
[    9.257554] Mount-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    9.260001] Mountpoint-cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    9.282601] process: using AMD E400 aware idle routine
[    9.282924] Last level iTLB entries: 4KB 512, 2MB 255, 4MB 127
[    9.283026] Last level dTLB entries: 4KB 512, 2MB 255, 4MB 127, 1GB 0
[    9.440226] Freeing SMP alternatives memory: 36K
[    9.572359] smpboot: CPU0: AMD QEMU Virtual CPU version 2.5+ (family: 0xf, model: 0x6b, stepping: 0x1)
[    9.579388] Performance Events: PMU not available due to virtualization, using software events only.
[    9.581419] rcu: Hierarchical SRCU implementation.
[    9.586782] NMI watchdog: Perf NMI watchdog permanently disabled
[    9.591036] smp: Bringing up secondary CPUs ...
[    9.594336] x86: Booting SMP configuration:
[    9.594446] .... node  #0, CPUs:      #1 #2 #3
[    9.793931] smp: Brought up 1 node, 4 CPUs
[    9.794082] smpboot: Max logical packages: 1
[    9.794157] ----------------
[    9.794201] | NMI testsuite:
[    9.794242] --------------------
[    9.794289]   remote IPI:  ok  |
[    9.795434]    local IPI:  ok  |
[    9.795851] --------------------
[    9.795934] Good, all   2 testcases passed! |
[...]

При передаче --nprocs=230 хэшеру (при аппаратной виртуализации) сквозной передачи в vm-run не произошло.

[...]
+ time qemu-system-x86_64 -M accel=kvm:tcg -m 230555M -smp cores=255 -nodefaults -nographic -no-reboot -fsdev local,id=root,path=/,security_model=none,multidevs=remap -device virtio-9p-pci,fsdev=root,mount_tag=virtio-9p:/ -device virtio-rng-pci -serial mon:stdio -kernel /usr/src/tmp/kernel-image-std-def-buildroot/boot/vmlinuz-5.10.153-std-def-alt1 -initrd /usr/src/tmp/initramfs-5.10.153-std-def-alt1.img -sandbox on,spawn=deny -bios bios.bin -append 'console=ttyS0 mitigations=off nokaslr  panic=-1 SCRIPT=/usr/src/tmp/tmp.qIxfAdCnPy NOTTY no_timer_check'
qemu-system-x86_64: warning: Number of SMP cpus requested (255) exceeds the recommended cpus supported by KVM (240)
qemu-system-x86_64: warning: Number of hotpluggable cpus requested (255) exceeds the recommended cpus supported by KVM (240)

[...]

[    3.144898]  #249
[    0.089863] kvm-clock: cpu 249, msr 1012a2e41, secondary cpu clock
[    3.147006] kvm-guest: stealtime: cpu 249, msr 37a8276080
[    3.151836]  #250
[    0.089863] kvm-clock: cpu 250, msr 1012a2e81, secondary cpu clock
[    3.154579] kvm-guest: stealtime: cpu 250, msr 37a82b6080
[    3.159829]  #251
[    0.089863] kvm-clock: cpu 251, msr 1012a2ec1, secondary cpu clock
[    3.162104] kvm-guest: stealtime: cpu 251, msr 37a82f6080
[    3.167941]  #252
[    0.089863] kvm-clock: cpu 252, msr 1012a2f01, secondary cpu clock
[    3.169951] kvm-guest: stealtime: cpu 252, msr 37a8336080
[    3.174829]  #253
[    0.089863] kvm-clock: cpu 253, msr 1012a2f41, secondary cpu clock
[    3.177637] kvm-guest: stealtime: cpu 253, msr 37a8376080
[    3.182867]  #254
[    0.089863] kvm-clock: cpu 254, msr 1012a2f81, secondary cpu clock
[    3.184655] kvm-guest: stealtime: cpu 254, msr 37a83b6080
[    3.189602] smp: Brought up 1 node, 255 CPUs
[    3.190583] smpboot: Max logical packages: 1
[    3.191582] ----------------
[    3.192583] | NMI testsuite:
[    3.193581] --------------------
[    3.194581]   remote IPI:  ok  |
[    3.196581]    local IPI:  ok  |
[    3.197610] --------------------
[    3.198581] Good, all   2 testcases passed! |
[    3.199581] ---------------------------------
[    3.200592] smpboot: Total of 255 processors activated (1249500.00 BogoMIPS)
[    3.227644] devtmpfs: initialized
[    3.228630] x86/mm: Memory block size: 128MB
[    3.240662] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns

После исправления spec-файла ядра и передачи vm-run параметра --cpu=220 количество ядер VM изменилось соответствующим образом:

[    4.458201] kvm-guest: stealtime: cpu 218, msr 37874b6080^M
[    4.463041]  #219^M
[    0.086574] kvm-clock: cpu 219, msr 1011766c1, secondary cpu clock^M
[    4.465454] kvm-guest: stealtime: cpu 219, msr 37874f6080^M
[    4.472809] smp: Brought up 1 node, 220 CPUs^M
[    4.473794] smpboot: Max logical packages: 1^M
[    4.474793] ----------------^M
[    4.475792] | NMI testsuite:^M
[    4.476792] --------------------^M
[    4.477792]   remote IPI:  ok  |^M
[    4.479793]    local IPI:  ok  |^M
[    4.480830] --------------------^M
[    4.481793] Good, all   2 testcases passed! |^M
[    4.482792] ---------------------------------^M
[    4.483805] smpboot: Total of 220 processors activated (1078000.00 BogoMIPS)^M

Вроде, все как задумано?
Comment 19 Николай Костригин 2022-11-18 15:39:37 MSK
Created attachment 11898 [details]
исправление сборки с gcc10 при бэкпорте в p10

Просьба эти изменения бэкпортировать и в p10.
Спасибо.
Comment 20 Vitaly Chikunov 2022-11-18 18:52:14 MSK
> При передаче --nprocs=230 хэшеру (при аппаратной виртуализации) сквозной передачи в vm-run не произошло.

На что влияет --nprocs= в hsh я не знаю. Я "пофиксил" лишь поддержку NPROCS переменной окружения - она задает максимальное значение (которое может быть и меньше в зависимости от других причин).
Comment 21 Vitaly Chikunov 2022-11-18 19:01:25 MSK
(In reply to Vitaly Chikunov from comment #20)
> На что влияет --nprocs= в hsh я не знаю.

На макрос %__nprocs, тогда можно добавить еще его поддержку.
Comment 22 Vitaly Chikunov 2022-11-18 20:00:00 MSK
Послал на сборку задание #310189 - должно все работать, наверное через час сделаю ему коммит и можно отправлять в p10.
Comment 23 Николай Костригин 2022-11-21 11:12:23 MSK
(Ответ для Vitaly Chikunov на комментарий #22)
> Послал на сборку задание #310189 - должно все работать, наверное через час
> сделаю ему коммит и можно отправлять в p10.

Спасибо. Отправил на тестирование в p10 в #310378