Hyper Threading в виртуальной машине

при этом смотрю virsh vcpuinfo, видно, что виртуальные «процессоры» постоянно соответствуют разным номерам реальных.

это вероятно можно исправить, настроив явный cpu pinning.

https://libvirt.org/formatdomain.html#elementsCPUTuning vcpupin.

Если сделать явно: 0-0, 1-1, и т.д., а будет ли это оптимально?
Например, если на хосте что-то делается (ведро конпеляется), оно займёт сначала первые потоки, и лучше, чтобы виртуалка в это время видела в качестве первого какой-то другой? Или даже несколько виртуальных потоков на один реальный.
Главное - чтобы при наличии ресурсов потоки на одном ядре и виделись как потоки на одном ядре. Как это проверить?

<выставляю в топологии> 2 потока
Если сделать явно: 0-0, 1-1, и т.д., а будет ли это оптимально?

Да.

Например, если на хосте что-то делается (ведро конпеляется), оно займёт сначала первые потоки, и лучше, чтобы виртуалка в это время видела в качестве первого какой-то другой?

Зачем? Компилятор перелезет на другой и все будет ОК, не?

Зачем? Компилятор перелезет на другой и все будет ОК, не?

Он сам поймёт, что надо перелазить на другой?
А если поток не загружен виртуалкой в данный момент (или загружен не на 100%), но запустится потом?

Если сделать явно: 0-0, 1-1, и т.д., а будет ли это оптимально?

не знаю, я такие конфигурации делал только из интереса (ну, кроме нумы, но с ней понятно более или менее), но не бенчмаркал.

я думаю, что экспериментировать и бенчмаркать — самый верный вариант.

плюс, скорее всего каким-нибудь cset'ом можно сделать так, чтоб хост на ненужные ядра для виртуалок не лазал.

Ты вообще в курсе, что поток не привязывается к ядру при рождении, а постоянно прыгает между ними?

плюс, скорее всего каким-нибудь cset'ом можно сделать так, чтоб хост на ненужные ядра для виртуалок не лазал.

о, ну все, если и после этого ТСа не отпустит паранойя, то это уже к психологам.

постоянно прыгает

В этом и дело, если сделать pinning, потоки будут отображаться однозначно. А виртуалка же сама не знает о том, что что-то запущено на хостовой системе, чтобы переносить свои потоки.

Какие бенчмарки проверяют это? (многопоточность с учётом HT)

поток не привязывается к ядру при рождении, а постоянно прыгает между ними?

Докажи своё утверждение. А то мне кажется, что так бывает не всегда.

Как насчет https://www.kernel.org/doc/Documentation/scheduler/sched-domains.txt, начиная с

Balancing within a sched domain occurs between [CPU] groups

?

Затрудняюсь дать внятную краткую выжимку, но

In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU through scheduler_tick().

... it runs load_balance() on that domain.

Initially, load_balance() finds the busiest group in the current sched domain.

... and starts moving tasks from it to our runqueue.

очень похоже на периодическую балансировку между CPU, обеспечивающую мое «постоянно прыгает между ними».

Миграция вроде кэш сбрасывает.

Насколько я знаю — да, и Linux на это чихал, ибо лучше сбросить L2, чем не мигрировать. Однако за истинность и свежесть не ручаюсь.

Как насчет https://www.kernel.org/doc/Documentation/scheduler/sched-domains.txt, начиная с

А как насчёт `man taskset`, например?

Пассиба, я знаю. У нас тут о поведении по умолчанию речь.

Какие бенчмарки проверяют это? (многопоточность с учётом HT)

у тебя академический или практический интерес?

если практический, то бенчмаркать надо на нагрузках, под которые виртуалка и делается, и выбирать оптимальную конфигурацию. ваш кэп.

Пассиба, я знаю. У нас тут о поведении по умолчанию речь.

Не нашёл упоминания «по умолчанию» во фразе «Ты вообще в курсе, что поток не привязывается к ядру при рождении, а постоянно прыгает между ними?».

Не нашёл упоминания «по умолчанию»

man «по умолчанию».