1.1, AlexAT (ok), 22:01, 19/11/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +12 +/– |
>>> Cистема выглядит как однопроцессорный сервер, показывающий производительность аналогичную производительности выделенного ядра CPU.
Ага, ЩАЗЗЗЗ. Это пока не уперлось в скорость памяти. Или в объем общего для ядер кеша. Или в шину. Или в диск. Т.е. в разделяемый ограниченный ресурс.
В том же ядре Linux очень много сделано для организации грамотного разделения данных ресурсов между задачами. Виртуализация в любом случае лишает ОС достоверных знаний о параметрах системы, поэтому о "выделенной производительности" лучше не петь.
Это не к тому, что виртуализация плоха. Это к тому, что заявленное, мягко говоря, лукаво. Если мерить чисто CPU командой NOP (утрирую) - да, действительно, будет очень близко. Если померить именно "как однопроцессорный сервер" - тут уже производительность будет плавать в зависимости от соседних площадок.
>>> Могут выполняться приложения, предназначенные для решения задач реального времени - выделение отдельного ядра CPU позволяет гарантировать отсутствие выполнения на данном CPU других задач
А гарантировать отсутствие соседней задачи на соседнем CPU, внезапно захотевшей обработать пару сотен гигов с диска, и за@#$вшей, простите, все кеши CPU, тоже при этом может? Если нет - для "задач реального времени" непригодно. Там совсем другие критерии.
---
В общем, штука неплоха по самой идее - определенно надо взять на заметку. Но вот маркетинговый булшит в очередной раз такой булшит...
Я даже примерно догадываюсь, в какую сторону идёт развитие... у Tilera примерно такой же способ организации выполнения задач, только в железе.
| |
|
|
3.23, AlexAT (ok), 07:03, 20/11/2013 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| –1 +/– |
> И зачем она тогда такая? Для декстопной виртуализации что-ли?
Не совсем. Ядер CPU на современных серверах и новых архитектурах становится прилично, и идеи по консолидации (уже давным давно) имеют место быть. То, что предлагается - разумный компромисс между "гибкой" виртуализацией со сквозной масштабируемостью, но высоким оверхедом на планирование, и отсутствием виртуализации вообще. Эдакое партиционирование - разделение системы на кусочки, со строгим выделением исполнительных блоков, при общем прочем ресурсе.
Вопрос в другом: есть ли в конечном счете смысл? Современные ультрамногоядерные архитектуры (как уже говорил, к примеру та же Tilera) вполне себе поддерживают партиционирование непосредственно в железе. Партиционирование любых платформ - идея интересная, но ядер всё-таки для полноценного использования на x86/ARM (пока что? к слову о векторе развития) маловато. Вопрос в том, что современное процессоростроение совершенно уперлось в предел частот и тепловыделения на мм кристалла, а значит дальше только вширь.
| |
|
|
3.26, AlexAT (ok), 07:32, 20/11/2013 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +1 +/– |
> Скорее всего зависит от задач. Можно сказать что это не "серебрянная пуля",
> но очень вкусная штука. Особенно учитывая что в реальных задачах сервера
> раскидывают как раз по ядрам ЦП и памяти. Если кто-то хочет
> чтоб работало со скоростью 1,5 ядра то это уже какие то
> специфичные задачи, или экономия ... хз где это надо ...
Тут немножко другое, не "1.5 ядра". На классических виртуализаторах машин (и ядер в машинах) может быть слегка больше, чем физических ядер - CPU является разделяемым ресурсом. Расчет делается на то, что основная масса машин 90% времени простаивает. Такая вот экономия.
В предлагаемом варианте - не виртуализация, а, как уже писал, партиционирование. Тупое деление физической площадки на виртуальные серверы в пределах емкости. Применения есть, весьма специфичные, но вполне себе есть. Навскидку - например, создание виртуальных роутеров в пределах одной физической площадки. Правда тут всё равно будут вопросы к поведению этой системы под высокой нагрузкой, когда кеша L3 или пропускной способности памяти слегка перестанет хватать.
> Задачи реального времени скорее всего хотят чистого CPU и памяти?
Задачи реального времени хотят предсказуемости времени исполнения в любой (штатной) ситуации. Если вдруг где-то возникает простой выше заданных рамок - RTOS перестает быть таковой.
| |
|
|
|
|
|
|
5.60, pavlinux (ok), 23:09, 21/11/2013 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
> Опять кто-то не догнал сути. Речь не о том, что бородатая NUMA
> новинка
> Сейчас NUMA на x86 в основном используется в контексте контроллера "на один
> физический процессор". Есть мысли о том, что скоро сие будет в
> контексте "на набор ядер внутри одного физического процессора". Сейчас контроллер внутри
> x86 пытается обслуживать все ядра одновременно, что для пресловутого партиционирования
> совершенно не есть комильфо, даже если каналов несколько. С учетом тенденций
> по росту вширь и виртуализации логично предположить, что несмотря на объединение
> множества ядер в одном кристалле контроллеры памяти в серверных решениях скоро
> станут индивидуальны для их групп.
Ну и какая хрен разница, что 16 процов на одной плате, что на одном кристалле.
Хочешь увидеть как это будет работать - пжалста CGROUP https://www.kernel.org/doc/Documentation/cgroups/memory.txt
| |
|
|
|
|
1.35, AnonymousRex (ok), 10:06, 20/11/2013 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +2 +/– |
вся новость выглядит так:
"мы пытались написать свой KVM только с возможностью тянуть RTOS, у нас не получилось, но если оставить только один процессор, и только с taskset-ом, то в принципе жить можно. а теперь мы попытаемся всем втереть что только так и надо работать, и плевать что 2013 год на дворе и однопроцессорные системы это не комильфо". очень напоминает маркетинговый бред vmware о том что один процессор в FT это хорошо, и еще более бредовые заявления мелкомягких о том что дедупликация памяти при виртуализации это плохо, хотя на самом деле они просто не смогли осилить фичу
| |
|
|
|
|
|
|
7.62, AnonymousRex (ok), 06:18, 23/11/2013 [^] [^^] [^^^] [ответить] [п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴┬ п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б┴╔п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б√⌠п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я▐Б√▓я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔я├Б∙╔я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б■■п©б╘п╠Б∙≤п©Б√▓п▒Б■╛Б┴╔п▒Б┬≥Б▄║я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б√═Б■─я▐Б√░п▒Б┬ Б√▒п©Б√▓п▒Б┬ Б∙░п▒Б┬ Б√▓]
| +/– |
> Замечательно, и опять это всё мне и без данного комментария известно. И
> опять никаких противоречий с моими словами. :)
> Аналогично и опять же, никак не противоречит моим словам.
ну тогда о чем спор? да, иногда дедупликацию не стоит использовать, но отменять ее тоже не стоит везде и всегда, это все что я хотел сказать
> Я прекрасно знаю. Но я то добавил "со своим UCS Director". Были
> на последнем CiscoConnect?
нет, я последние полгода out of the loop - занимаюсь другими вещами
> Это намного легче, чем кажется. Буквально недавно читал статью про атаку через
> L3 Cache. Оказывается тут необходима не слишком высокая квалификация, чтобы это
> применять. Этот класс атак явно недооценивают, IMHO.
> Если хотите, могу скинуть ссылку.
я в принципе уже нагуглил несколько. надо будет Дэна Волша спросить есть ли у него ответ через sVirt
> Каждое предприятие само выставляет свои приоритеты. Кто-то вообще работает по принципу
> "неуловимого Джо" и ему на всё насрать (и забавно, что это
> зачастую работает). Однако фактически в любой средней/крупной конторе есть какие-то системы,
> которые должны быть очень хорошо защищены, иначе им может стать очень
> больно. Кроме того, "невзламываемость" - это вопрос престижа, если контора связана
> с IT.
для многих защита это нормальный бекап, и экономия на железе намного важнее. но это конечно же все индивидуально
> В общем, вся моя мысль заключалась в том, что в отключении дедупликации
> есть свой смысл, который по-моему неоспорим для конкретных ситуаций.
конечно есть, я и не спорю
| |
|
|
|
|
|
|
|