Bug 44337

Created attachment 11880 [details]
предлагаемое исправление

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

"6.2" это значит qemu не из Сизифа? Не могли бы вы проверить что в Сизифе 256 тоже дает ошибку? 

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

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

Нету. 

TODO: Может потом придумаем как это исправить лучше. И думаю --nprocs должно поддерживаться.

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

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

Пока не стал собирать пакет:
может быть, все таки починить более кардинально?
Пока тестируемое ядро 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)

А что это за пакет таймаутит?

(In reply to Vitaly Chikunov from comment #5)
> А что это за пакет таймаутит?

Если std/un-def ядро, то там же таймаут 300 и 999 секунд. (А во втором случае еще надо время чтоб прогнать все тесты.) Неужто ядро грузится больше 300 секунд?

(In reply to Vitaly Chikunov from comment #6)
> Неужто ядро грузится больше 300 секунд?

Если да, то это не связанная проблема. И вам надо или пропускать %check или придумывать решение, может есть какие-то опции чтоб ускорить загрузку с 255 cpu. Есть ли лог?

(Ответ для Vitaly Chikunov на комментарий #7)
> (In reply to Vitaly Chikunov from comment #6)
> > Неужто ядро грузится больше 300 секунд?
> 
> [...]

Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и, соответственно, отсутствие аппаратной виртуализации - поэтому так долго.
Если существуют сценарии такого использования, то таймаут маловат. Если не существует, то после проброса должно заработать. Проверю.

Одно из решений, но видимо не оптимальное - добавить в 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 загрузки, чтоб узнать правильное значение (то есть не универсально и нельзя выставить заранее) и при неправильном значении может приводить к ошибкам в работе ядра.

(In reply to Николай Костригин from comment #8)
> Скорее всего виновато отстутствие проброса /dev/kvm в хэшер и,
> соответственно, отсутствие аппаратной виртуализации - поэтому так долго.

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

  timeout 300 vm-run uname -a

(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 системе!

(Ответ для Николай Костригин на комментарий #8)
> > [...]
> 
> Скорее всего виновато отстутствие проброса /dev/kvm в хэшер
> [...]
> Проверю.

Все так и есть. C /dev/kvm собирается нормально и проходит тесты.
task #310175: try #1 is AWAITING

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

Ок я потом сделаю - если точно нет kvm то maxcpu, скажем, 4.

(In reply to Vitaly Chikunov from comment #2)
> И думаю --nprocs должно поддерживаться.

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

  [ -v NPROC ] || NPROC=$(nproc)

Сделал тестовое задание
https://git.altlinux.org/tasks/310189/
- vm-run: Define MAXCPU=255 for x86_64
- пофикшена поддержка NPROCS
- при отсутствии KVM ограничивает MAXCPU=4
- Экспериментально, --cpu= устанавливает любое кол-во ядер, которое запросил пользователь, то есть эта опция для экспериментов в hsh-shell "что будет если столько-то ядер", а не для спеков/продакшена.

Кстати, у меня без 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

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).

(Ответ для 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

Вроде, все как задумано?

Created attachment 11898 [details]
исправление сборки с gcc10 при бэкпорте в p10

Просьба эти изменения бэкпортировать и в p10.
Спасибо.

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

На что влияет --nprocs= в hsh я не знаю. Я "пофиксил" лишь поддержку NPROCS переменной окружения - она задает максимальное значение (которое может быть и меньше в зависимости от других причин).

(In reply to Vitaly Chikunov from comment #20)
> На что влияет --nprocs= в hsh я не знаю.

На макрос %__nprocs, тогда можно добавить еще его поддержку.

Послал на сборку задание #310189 - должно все работать, наверное через час сделаю ему коммит и можно отправлять в p10.

(Ответ для Vitaly Chikunov на комментарий #22)
> Послал на сборку задание #310189 - должно все работать, наверное через час
> сделаю ему коммит и можно отправлять в p10.

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