Pull to refresh

Comments 13

Статьи amarao про облачные вычисления самые интересные и познавательные… Не перестаю убеждаться в этом.
UFO just landed and posted this here
Заблуждение что HTТ даст нам «больше ядер» берёт своё начало в непонимании собственно главного «что такое HT». Увы почитав даже поверхностно хотя бы вики, всё встанет на свои места. (Увы HTT даёт нам «два ядра», далеко не во всех случаях. Причём «два ядра» именно в кавычках.)
В тестах с чистой математикой HT давал полуторакратный прирост производительности. HT — это эмуляция двух pcpu на базе вычислительных возможностей одного CPU. Из-за конвееров и кучи компонент они в результате назгружаются больше.
Ваша тирада сводится к тому, что неправильно считается время цпу? Или к тому, что использовать HT, выдавая на одном i7 или аналоге 7 CPU 7 виртуалкам — неэффективно?
А выделять пользователю один реальный ЦПУ, но при включённом HT так, чтоб он делал свои дела раза в полтора быстрее за те же деньги — не получается?
Прозреваю, что для этого надо патчить Xen, причём ощутимо так.
Сколько времени при этом будет работать каждое ядро? Дело в том, что HT изначально ущербный (в своё время было много флейма по поводу слетающих приоритетов у процессов из-за того, что на соседнем недо-ядре idle-задача 100% жрёт). В скедулере это научились учитывать, но и только. Когда у нас есть недоядра, мы не можем сказать в каждый момент времени, работает оно как «полное ядро» или как «недоядро». Лучшее, что можно — это не вешать процессы параллельно на два недоядра, относящиеся к одному ядру. Но это лишь планирование процессов (доменов, не важно). А вот как его учитывать? «неполноценное время»?

Дальше проблема, если у человека однопоточное приложение. Если мы «недоядра» не загружаем на 100%, то в чём смысл HT, кроме «побольше строчек в /proc/cpuinfo»? А если загружаем, то может оказаться так, что человек получает для двух однопоточных приложений меньшую производительность, чем если бы у него было два ядра.

И зачем нам людям портить скорость работы? Чтобы анонсировать «14-16» ядер в виртуалку?

Если мухлевать, то я даже сейчас могу анонсировать 100+ ядер в виртуалку. Только работать они будут большей частью времени по-очерёдно, а не парраллельно.
Расскажите, пожалуйста, про мухлёж!
Интересно, как такое делают.
элементарно и глупо. Зен при создании домена анонсирует некоторое количество виртуальных процессоров. Дальше операционка домена (допустим, линукс), планирует процессы к выполнению и использует их как обычные процессоры.

Дальше, когда нужно выполнить процесс, ядро пытается выполнять что-то на заданном vcpu. А зен получив запрос на выполнение кода на данном vcpu решает, на каком физическом процессоре это сделать.

Нормальный режим — VCPU ≤ PCPU (VCPU каждой виртуалки). Если сделать VCPU > PCPU, то некоторые VCPU будут блокированы (если простаивают, сами, если загружены, то скедулером зена). В результате будет выполняться одновременно виртуальных процессоров не более, чем есть физических (в общем случае). В результате, если загрузка реально больше числа процессоров, то оно будет тормозить больше, чем если бы анонсировалось разумное количество. А если нагрузка меньше — то это глупость и баловство.
Они дают все процессоры виртуалкам, читайте внимательнее.
Довольно элегантно удалось разобраться со всеми описанными проблемами, поздравляю!
Немного обратная формулировка — выписаны только те проблемы, для которых удалось найти элегантное решение.
Sign up to leave a comment.

Articles