Мне кажется или Вы уже сделали вывод, а сейчас пытаетесь подвести под него «факты»?
Даже если хотплаг и дорогая операция (я не знаю — так что не могу ничего утверждать), это вообще ничего не меняет. Вместо того, чтоб выделять таблиц сразу на все 64 гига, к примеру, мы выделяем только на 1 гиг доводим хотплагом до того, что реально нужно виртуалке и дальше она использует только балунинг. Другими словами это тот же балунинг, но с адаптивным выделением места под таблицы страниц (и TLB, кстати, который дороже даже самой физической памяти).
Чтобы пояснить мысль, напомню, что std::stack в C++ чаще всего реализуется на основе std::deque. Ресайз дека — операция весьма дорогая (и из-за operator new и из-за необходимости поэлементного копирования всего содержимого), но тем не менее асимптотически операции push/pop в таком стеке имеют константную сложность. Просто потому, что дек достаточно быстро выходит на steady state и ни новых обращений к хипу ни новых копирований содержимого уже не нужно.
Ну то есть Вы автоматически записываете девелоперов МС в «тупые индусы». У них и оба механизма есть (balloning и hot-add) и средства для диагностики (ETW/xperf), а они возьми да и выкати неэффективное решение. А хотплаг скорее всего случается по прерыванию, так что активно ничего поллить не нужно.
Блин, отослалось как то. Так вот, hot-add память насколько я понял не может появляться где попало — только в строго отведенных местах и ОС в принципе может подготовиться к этому.
Ну во первых перестраивать PDE/PTE умеют вообще все ОС, которые умеют изоляцию процессов и виртуальную память.
Но насколько я понял, Вы о памяти ядра (там тоже каждое выделение памяти меняет эти таблицы). Наверное по какой то причине ОС не может добавлять новые директории/таблицы. Посмотрел ядро линукса — честно говоря запутался (и как назло ни комментариев нормальных ни документации). Там мемори менеджмент очень сильно закаплен с xen/kvm (или чего там в качестве виртуалки), что в общем не так уж и плохо — ибо data hiding приносится в жертву производительности.
В общем, не могу утверждать на 100%, но из того, что я увидел, память добавляется при помощи arch-specific функции arch_add_memory, которая зовет сначала init_memory_mapping а потом __add_pages. init_memory_mapping проходит в цикле по страницам и для каждой зовет kernel_physical_mapping_init и ближе к концу зовет __flush_tlb_all (что свидетельствует о том, что меппинги изменились — иной причины сбрасывать кеши этих меппингов я не вижу). kernel_physical_mapping_init уже уходит куда то в VM. __add_pages в свою очередь зовет в цикле __add_section, та зовет sparse_add_one_section, __add_zone и register_new_memory
В общем, как я уже сказал, не могу утверждать со всей уверенностью, но очень вероятно, что даже линукс перемапливает директории/таблицы при добавлении памяти. Так что аргумент «хот-адд для уменьшения мемори футпринта» остается в силе
Глупо потому что «индусы из Редмонда» или у Вас есть конкретные претензии?
Я вижу только то, что для несуществующей памяти не нужно выделать таблицы/директории и соответственно нет оверхеда. Ну а после того, как память хотплагнулась — деваться некуда — приходится пользовать балулнинг.
Конкретно про юникс: как и в случае с модульностью, с простотой в юниксах — полный швах, хотя сам принцип и имеет право на жизнь.
Лучший пример принципа «Зачем нам дизайн, если можно сделать ОВЕРдизайн» — это знаменитый x.org
Я не разбираюсь в X настолько глубоко, как Julien Danjou, но для того, чтобы понять насколько там все печально достаточно подумать о том, когда Вы в последний раз использовали сетевые возможности X вместо, скажем, vnc? Кроме того, что эти сетевые возможности практически нигде не используются, они открывают забавный вектор атаки (подозреваю, что в переусложненном коде 80-х годов, который никто уже не понимает есть некоторое количество ошибок) — одной из которых долгое время являлась возможность снятия keylog-а с удаленной системы, не имея даже аккаунта на ней. С появлением xauth осталась только возможность делать keylog ЛЮБОЙ активности на десктопе (в том числе gksudo, терминала и вообще всех рутовых процессов) из-под непривилегированного пользователя.
Чтобы обойти высокую латентность и низкую пропускную способность сетевых протоколов, в конце концов появляются расширения типа MIT-SHM, которые полностью отказываются от сетевых возможностей во имя производительности, при этом все еще оставляя видимость, что все таки происходит по сети. Этого оказывается мало и появляется DRI/DRM, имеющий полный доступ к аппаратуре и физической памяти, но «для галочки» работающий как user-mode процесс.
Да и сама юзермодовость X сервера — не более, чем «потемкинская деревня» для демонстрации как все хорошо. Если углубиться в детали, оказывается что он работает от root-а, что в сочетании с довольно дурацкой юникс-безопасностью автоматически означает то же, что и kernel-mode модуль — то есть полное и ничем неограниченное доверие (даже если кому то захочется ограничить x сервер с помощью какого нибудь LSM, о которых отдельный разговор, то придется оставить R/W доступ на /dev/mem, что опять таки означает полный и ничем не ограниченный доступ к системе).
Был ли выучен урок? не думаю (зато аудиостек нативно поддерживает стриминг по сети, кроме случаев, когда он вообще не работает).
Это был ответ на «Как раз именно за модульность я и люблю Unix-системы». Подразумевается неявное сравнение «с не-Unix-системами». Неоднократно встречал эдакий юникс-снобизм как раз таки в духе «в мире юникс все идеально».
негативные примеры нужно будет не искать специально, а из них будет построено вообще все
Самое забавное, что модульность не имеет отношения к юниксу, а имеет к программированию вообще (и не только программированию — модуляризация и использование шаблонов пришли в само программирование извне). Более того, как раз в юниксе такие примеры и не надо искать специально — таких примеров на каждом шагу. Недодумки с безопасностью (даже SUS сейчас стеснительно называет суперпользователя «appropriate privileges», но все равно уши торчат в виде chmod в том же стандарте), недодумки с моделью исполнения (вот список функций, связанных с СОЗДАНИЕМ единицы исполнения: fork, fork1, forkall, pthread_create, pthread_atfork, posix_spawn, posix_spanwp, execl, execle, execlp, execv, execve, execvp, fexecve, system, может еще чего забыл), недодумки с файловыми абстракциями (функции для ОТКРЫТИЯ/СОЗДАНИЯ файла: open, fopen, fdopen, creat, popen, opendir, fdopendir, tmpfile, mkdir, mkdirat, может еще чего — причем для каждой функции из этого зоопарка существует отдельная функция закрытия).
А ведь это самые базовые вещи, основы которых были заложены наверное еще до появления юникса. Что уж говорить о шелле и текстовых пайпах, настолько неудобных, что люди предпочитают создавать огромные комбайны, которые делают все в один проход (типа ImageMagick), дублировать функционал (как в приведенных выше примерах), создавать на лету «новые скрипты» (xargs, find — последний еще и дублирует функционал кучи утилит типа ls, grep, stat и пр) и используют десятки других ухищрений — все только для того, чтобы избежать использования пайпа.
Причем тот же SUS описывает весьма небольшую часть функционала: ничего не сказано о графической подсистеме, мультимедиа стеках, модели драйверов и пр… И вот в том же линуксе со всеми этими «расширениями» творится такой же бардак, как и в самом стандарте.
Второе, что искажается, это«блок должен выполнять только одну задачу»
Так это же из юникс философии. И необходимость текстовых пайпов — тоже оттуда.
Более того, как раз пример с ноутбуком некорректен. Ноутбук состоит из тех же шин и компонентов, что и «большие» компьютеры — просто они не всегда «user serviceable». Более корректным будет пример SoC.
Ага, модульность. Уникальные возможности plaintext-овых пайпов. Do one thing right.
Есть «модуль», перечисляющий процессы — называется ps
Есть «модуль», умеющий искать паттерны — называется grep
Есть «модуль», посылающий процессам сигналы — называется kill
Прекрасно. Как же нам найти процессы по шаблону и послать им сигнал? Наверное так:
ps | grep <options> | kill <options>
Хм, не совсем. Надо густо перемазывать все sed/awk. Но вдруг нам не хочется связываться с парсингом. ОК есть -C cmdlist: ps пытается делать работу grep, но делает это плохо (one thing right, да-да). Поэтому появляется pgrep, который умеет еще и регулярные выражения. Ок, ну дальше то все нормально да?
pgrep <options> | kill <options>
Уж это то точно должно работать. Правда, ведь?
Не так быстро. Теперь нужно обмазываться не только sed/awk, но еще и xargs. А если нам не хочется? Ну придется делать еще одну «one thing» — нам не привыкать. Итак, на сцене…
pkill — комбайн, включающий в себя целых ТРИ модуля. Просто потому, что не только каждый «модуль» по отдельности не справляется со своими задачами, но даже комбинации два-в-одном — тоже не особо помогают.
А есть еще killall и skill. А также pstree и top (последний в основном потому, что «модуль» sort хреново справляется с задачей сортировки выхлопа из «модуля» ps).
«Do as I Say Not as I Do» в чистом виде. А вообще забавно, берется прописная истина (недаром работы одного архитектора по шаблонизации и модуляризации так ценятся в CS с середины прошлого века), и легким движением руки приписываются себе (желательно еще приписать это ТОЛЬКО себе — но это не всегда возможно). Особый шик, если у тебя получается всячески нарушать эту прописную истину, но при этом убедить всех в том, что только ты ее и соблюдаешь.
Не нужно всем гарантированно правильно определять свой цвет. Нужно, чтобы ХОТЬ ОДИН гарантированно определил свой цвет. И Вы совершенно верно разбили задачу на варианты. Дальше решение для двух мудрецов тривиально.
Думаю, чтоб люди не искали вероятностные решения, стоит добавить условие о «full disclosure», то есть королю известно ВСЕ, о чем договорятся мудрецы и он может выбирать цвета шапок так, чтобы минимизировать/исключить вероятность выигрыша мудрецов исходя из заранее известной стратегии.
Не хочу спойлерить, но дам подсказку: чтоб толкнуть мысль в правильном направлении можно сначала решить достаточно тривиальный случай для двух цветов и двух мудрецов, а уж потом обобщать на N цветов/N мудрецов.
Решение для двух цветов может, кроме прочего, убедить неверующих существовании гарантированной стратегии выигрыша.
Да, насчет «никогда не говорил» я погорячился. Похоже это надо перефразировать «никогда до этого не говорил» — но это не столь важно.
А вот насчет остального — совершенно непонятно, чего Вы пытаетесь доказать. И «проблемы нет — держите правильно» было, и «другие не лучше» (более того, именно на этом был основной акцент, а не на «we're not perfect»). У эппла есть проблема в дизайне антенны, которая отсутствует у других. В комбинации с «Мы не знаем как обойти законы физики. Пока» (в применении к экранированию антенны рукой/головой) получается довольно печальная картина.
А вообще давайте определимся с предметом спора. Вы считате, что игнорирование факта наличия «The Spot» и попытка концентрации общественного внимания ТОЛЬКО на экранировании — это правильно и честно?
Нет, эппл не говорит (и никогда не говорил) «Мы не идеальны». Им со стороны сказали: «У вас грубая ошибка в дизайне антенны». На что они ответили сначала «Проблем нет, держите правильно», а потом «А другие не лучше». Причем это обычное для эппл передергивание: ни у одного из приведенных телефонов нет такой точки, касание к которой снижает качество приема (но самый большой просчет в том, что даже при том, что такая точка есть — ее можно было бы разместить подальше от мест, которых касается рука при нормальной работе)
Дадад, обзывая всех несогласных «хомячками», Вы очень эффективно призываете к дискуссии.
Есть два неоспоримых факта:
1. Человеческое тело состоит в основном из солененькой водички (электролита), которая очень неплохо проводит электричество и имеет низкую прозрачность в для большого спектра э/м излучения. У любой антенны (в том числе у антенн всех мобильных телефонов) снижается качество принимаемого сигнала, если ее экранировать проводником
2. У ОДНОГО телефона есть «The Spot» при ПРИКОСНОВЕНИИ к которому очень сильно падает качество принимаемого сигнала (о чем Вам, в отличие от большинства других «умиляющихся хомячков», известно)
Итого, у айфона есть ДВЕ проблемы, одна из которых связана с ДИЗАЙНОМ антенны, в то время как у других производителей — только одна. Эппл пытается отбрехаться, указывая на первую проблему, в то время как все говорят о второй (вернее первая подразумевается по умолчанию и даже не обсуждается — ибо обсуждать нечего). Довольно интересное передергивание (хотя и вполне ожидаемое в случае Эппл)
А при чем здесь «инженеры Microsoft»? Exchange скейлится довольно неплохо: в том же MS 90+ тысяч только фултайм сотрудников, не говоря уже о контракторах и о том, что у этих сотрудников по несколько девайсов, синхронизирующихся с эксченджем (мейловый десктоп, ноут, телефон и пр). Тут уж масштабируйся-не масштабируйся, а если выбранное количество серверов не рассчитано на удесятеренную нагрузку, то они в любом случае умрут.
По такому принципе работает Skyfire. Видео смотреть практически нереально — нет, что то рендерится, но назвать ЭТО «видео» я не могу. Даже на приведенных видео видно, что более-менее статичные сцены превращаются в слайдшоу (подозреваю очень широкий канал, потому что у меня на 5Mbps/Snapdragon все было еще печальнее), что уж говорить о динамичных
Даже если хотплаг и дорогая операция (я не знаю — так что не могу ничего утверждать), это вообще ничего не меняет. Вместо того, чтоб выделять таблиц сразу на все 64 гига, к примеру, мы выделяем только на 1 гиг доводим хотплагом до того, что реально нужно виртуалке и дальше она использует только балунинг. Другими словами это тот же балунинг, но с адаптивным выделением места под таблицы страниц (и TLB, кстати, который дороже даже самой физической памяти).
Чтобы пояснить мысль, напомню, что std::stack в C++ чаще всего реализуется на основе std::deque. Ресайз дека — операция весьма дорогая (и из-за operator new и из-за необходимости поэлементного копирования всего содержимого), но тем не менее асимптотически операции push/pop в таком стеке имеют константную сложность. Просто потому, что дек достаточно быстро выходит на steady state и ни новых обращений к хипу ни новых копирований содержимого уже не нужно.
Но насколько я понял, Вы о памяти ядра (там тоже каждое выделение памяти меняет эти таблицы). Наверное по какой то причине ОС не может добавлять новые директории/таблицы. Посмотрел ядро линукса — честно говоря запутался (и как назло ни комментариев нормальных ни документации). Там мемори менеджмент очень сильно закаплен с xen/kvm (или чего там в качестве виртуалки), что в общем не так уж и плохо — ибо data hiding приносится в жертву производительности.
В общем, не могу утверждать на 100%, но из того, что я увидел, память добавляется при помощи arch-specific функции arch_add_memory, которая зовет сначала init_memory_mapping а потом __add_pages. init_memory_mapping проходит в цикле по страницам и для каждой зовет kernel_physical_mapping_init и ближе к концу зовет __flush_tlb_all (что свидетельствует о том, что меппинги изменились — иной причины сбрасывать кеши этих меппингов я не вижу). kernel_physical_mapping_init уже уходит куда то в VM. __add_pages в свою очередь зовет в цикле __add_section, та зовет sparse_add_one_section, __add_zone и register_new_memory
В общем, как я уже сказал, не могу утверждать со всей уверенностью, но очень вероятно, что даже линукс перемапливает директории/таблицы при добавлении памяти. Так что аргумент «хот-адд для уменьшения мемори футпринта» остается в силе
s/балулнинг/балунинг/
Надо перечитывать перед отправкой, надо перечитывать перед отправкой
Я вижу только то, что для несуществующей памяти не нужно выделать таблицы/директории и соответственно нет оверхеда. Ну а после того, как память хотплагнулась — деваться некуда — приходится пользовать балулнинг.
Лучший пример принципа «Зачем нам дизайн, если можно сделать ОВЕРдизайн» — это знаменитый x.org
Я не разбираюсь в X настолько глубоко, как Julien Danjou, но для того, чтобы понять насколько там все печально достаточно подумать о том, когда Вы в последний раз использовали сетевые возможности X вместо, скажем, vnc? Кроме того, что эти сетевые возможности практически нигде не используются, они открывают забавный вектор атаки (подозреваю, что в переусложненном коде 80-х годов, который никто уже не понимает есть некоторое количество ошибок) — одной из которых долгое время являлась возможность снятия keylog-а с удаленной системы, не имея даже аккаунта на ней. С появлением xauth осталась только возможность делать keylog ЛЮБОЙ активности на десктопе (в том числе gksudo, терминала и вообще всех рутовых процессов) из-под непривилегированного пользователя.
Чтобы обойти высокую латентность и низкую пропускную способность сетевых протоколов, в конце концов появляются расширения типа MIT-SHM, которые полностью отказываются от сетевых возможностей во имя производительности, при этом все еще оставляя видимость, что все таки происходит по сети. Этого оказывается мало и появляется DRI/DRM, имеющий полный доступ к аппаратуре и физической памяти, но «для галочки» работающий как user-mode процесс.
Да и сама юзермодовость X сервера — не более, чем «потемкинская деревня» для демонстрации как все хорошо. Если углубиться в детали, оказывается что он работает от root-а, что в сочетании с довольно дурацкой юникс-безопасностью автоматически означает то же, что и kernel-mode модуль — то есть полное и ничем неограниченное доверие (даже если кому то захочется ограничить x сервер с помощью какого нибудь LSM, о которых отдельный разговор, то придется оставить R/W доступ на /dev/mem, что опять таки означает полный и ничем не ограниченный доступ к системе).
Был ли выучен урок? не думаю (зато аудиостек нативно поддерживает стриминг по сети, кроме случаев, когда он вообще не работает).
xkcd 619 появилось не на пустом месте, да
Hot или не-hot, но анплаг определенно есть
негативные примеры нужно будет не искать специально, а из них будет построено вообще все
Самое забавное, что модульность не имеет отношения к юниксу, а имеет к программированию вообще (и не только программированию — модуляризация и использование шаблонов пришли в само программирование извне). Более того, как раз в юниксе такие примеры и не надо искать специально — таких примеров на каждом шагу. Недодумки с безопасностью (даже SUS сейчас стеснительно называет суперпользователя «appropriate privileges», но все равно уши торчат в виде chmod в том же стандарте), недодумки с моделью исполнения (вот список функций, связанных с СОЗДАНИЕМ единицы исполнения: fork, fork1, forkall, pthread_create, pthread_atfork, posix_spawn, posix_spanwp, execl, execle, execlp, execv, execve, execvp, fexecve, system, может еще чего забыл), недодумки с файловыми абстракциями (функции для ОТКРЫТИЯ/СОЗДАНИЯ файла: open, fopen, fdopen, creat, popen, opendir, fdopendir, tmpfile, mkdir, mkdirat, может еще чего — причем для каждой функции из этого зоопарка существует отдельная функция закрытия).
А ведь это самые базовые вещи, основы которых были заложены наверное еще до появления юникса. Что уж говорить о шелле и текстовых пайпах, настолько неудобных, что люди предпочитают создавать огромные комбайны, которые делают все в один проход (типа ImageMagick), дублировать функционал (как в приведенных выше примерах), создавать на лету «новые скрипты» (xargs, find — последний еще и дублирует функционал кучи утилит типа ls, grep, stat и пр) и используют десятки других ухищрений — все только для того, чтобы избежать использования пайпа.
Причем тот же SUS описывает весьма небольшую часть функционала: ничего не сказано о графической подсистеме, мультимедиа стеках, модели драйверов и пр… И вот в том же линуксе со всеми этими «расширениями» творится такой же бардак, как и в самом стандарте.
Второе, что искажается, это«блок должен выполнять только одну задачу»
Так это же из юникс философии. И необходимость текстовых пайпов — тоже оттуда.
Более того, как раз пример с ноутбуком некорректен. Ноутбук состоит из тех же шин и компонентов, что и «большие» компьютеры — просто они не всегда «user serviceable». Более корректным будет пример SoC.
Есть «модуль», перечисляющий процессы — называется ps
Есть «модуль», умеющий искать паттерны — называется grep
Есть «модуль», посылающий процессам сигналы — называется kill
Прекрасно. Как же нам найти процессы по шаблону и послать им сигнал? Наверное так:
ps | grep <options> | kill <options>
Хм, не совсем. Надо густо перемазывать все sed/awk. Но вдруг нам не хочется связываться с парсингом. ОК есть -C cmdlist: ps пытается делать работу grep, но делает это плохо (one thing right, да-да). Поэтому появляется pgrep, который умеет еще и регулярные выражения. Ок, ну дальше то все нормально да?
pgrep <options> | kill <options>
Уж это то точно должно работать. Правда, ведь?
Не так быстро. Теперь нужно обмазываться не только sed/awk, но еще и xargs. А если нам не хочется? Ну придется делать еще одну «one thing» — нам не привыкать. Итак, на сцене…
pkill — комбайн, включающий в себя целых ТРИ модуля. Просто потому, что не только каждый «модуль» по отдельности не справляется со своими задачами, но даже комбинации два-в-одном — тоже не особо помогают.
А есть еще killall и skill. А также pstree и top (последний в основном потому, что «модуль» sort хреново справляется с задачей сортировки выхлопа из «модуля» ps).
«Do as I Say Not as I Do» в чистом виде. А вообще забавно, берется прописная истина (недаром работы одного архитектора по шаблонизации и модуляризации так ценятся в CS с середины прошлого века), и легким движением руки приписываются себе (желательно еще приписать это ТОЛЬКО себе — но это не всегда возможно). Особый шик, если у тебя получается всячески нарушать эту прописную истину, но при этом убедить всех в том, что только ты ее и соблюдаешь.
Не хочу спойлерить, но дам подсказку: чтоб толкнуть мысль в правильном направлении можно сначала решить достаточно тривиальный случай для двух цветов и двух мудрецов, а уж потом обобщать на N цветов/N мудрецов.
Решение для двух цветов может, кроме прочего, убедить неверующих существовании гарантированной стратегии выигрыша.
А вот насчет остального — совершенно непонятно, чего Вы пытаетесь доказать. И «проблемы нет — держите правильно» было, и «другие не лучше» (более того, именно на этом был основной акцент, а не на «we're not perfect»). У эппла есть проблема в дизайне антенны, которая отсутствует у других. В комбинации с «Мы не знаем как обойти законы физики. Пока» (в применении к экранированию антенны рукой/головой) получается довольно печальная картина.
А вообще давайте определимся с предметом спора. Вы считате, что игнорирование факта наличия «The Spot» и попытка концентрации общественного внимания ТОЛЬКО на экранировании — это правильно и честно?
Есть два неоспоримых факта:
1. Человеческое тело состоит в основном из солененькой водички (электролита), которая очень неплохо проводит электричество и имеет низкую прозрачность в для большого спектра э/м излучения. У любой антенны (в том числе у антенн всех мобильных телефонов) снижается качество принимаемого сигнала, если ее экранировать проводником
2. У ОДНОГО телефона есть «The Spot» при ПРИКОСНОВЕНИИ к которому очень сильно падает качество принимаемого сигнала (о чем Вам, в отличие от большинства других «умиляющихся хомячков», известно)
Итого, у айфона есть ДВЕ проблемы, одна из которых связана с ДИЗАЙНОМ антенны, в то время как у других производителей — только одна. Эппл пытается отбрехаться, указывая на первую проблему, в то время как все говорят о второй (вернее первая подразумевается по умолчанию и даже не обсуждается — ибо обсуждать нечего). Довольно интересное передергивание (хотя и вполне ожидаемое в случае Эппл)
200..225|% {nslookup 62.76.96.$_}
Но для повышения читаемости лучше сделать хотя бы
200..225|% {nslookup 62.76.96.$_}|select-string "^Name:"
Или вообще так:
200..225 |% {[net.dns]::GetHostByAddress(«62.76.96.$_»).hostname}
Здесь можно посмотреть «вживую» www.youtube.com/watch?v=p8QtIsVkPd0
Есть отверстие для