При использовании многопоточного ЦП можно ли рассматривать поток как ядро, чтобы удвоить количество доступных ядер по сравнению с гостевой ОС?
1 ответ
2
Предполагая, что вы имеете в виду «поток» в том же смысле, что и поток выполнения, обеспечиваемый такими технологиями, как Intel HyperThreading, или реализациями SMT в AMD Ryzen (или Sun/Oracle/ кто угодно UltraSPARC, или любым другим числом платформ), тогда да, но, вероятно, не по причинам, которые вы могли бы подумать.
На низком уровне «потоки» в данном ядре имеют некоторую форму общих ресурсов, хотя то, что они совместно используют, зависит от реализации (почти весь общий кэш, но помимо этого это своего рода удар или промах). Однако в том, что касается пользовательских приложений, они ничем не отличаются от отдельных ядер (некоторые платформы различают физические ЦП (количество пакетов на ядро в пакете) от логических ЦП (количество потоков на ядро и время пакетов). ), но реально пользовательские программы почти никогда не относятся к ним по-другому).
В случае QEMU это фактически полностью отделено от того, что он предоставляет гостевой системе. По умолчанию он содержит ровно одно ядро и ничего не раскрывает в топологии оборудования хост-системы. С использованием опции -smp для предоставления произвольных топологий. Имея только число, он моделирует один ЦП с таким количеством ядер, но для многих платформ вы можете указать точные значения количества ядер в пакете, количества потоков в ядре и количества доступных сокетов. Таким образом, теоретически вы могли бы выставить 8 ядер с 2 TPC (нитями на ядро) Ryzen 7 для гостя QEMU как 16 независимых ядер, или одно ядро с 16 потоками, или даже как 16 отдельных пакетов ЦП с 1 ядро каждого. Вы даже можете предоставить гостю больше виртуальных ядер, чем физических систем в системе, и в этом случае эти ядра будут мультиплексированы между всеми физическими процессорами, которые у вас есть (это действительно полезно для тестирования).