Спасибо, за статью. Любители радиации урановое стекло ищут на блошках, и бывает за копейки его отдают продавцы. Фанаты ручной заточки ищут старые натуральные заточные камни типа бритвенного J.G. ESCHER(бывает у людей дед с войны как трофей привез и у кого-то лежал на даче или в деревне), Belgian Blue Whetstone, советские высококачественные байкалиты, арканзасы, вашиты и т.д… Но скорее всего в Москве на блошках большая часть продавцов уже прошаренные и цены завышают на этот товар, и есть не мало охотников на лакомые позиции. Но все равно выгоднее купить чем в интернете на вторичке.
Спасибо КЭП за разъяснение! У меня такое чувство, что люди совсем не читали статью и комментарии, сами себе чето-то надумали сами же на свой вопрос ответили…
yield() или sleep() это совсем другой случай, про это мной нигде не было написано. Поток даже может не вызвать yield() или sleep(). Ваши знания как раз видимо и spin loop ограничены…
И вы упустили самый главный момент, что yield() или sleep() займет суммарно значительно больше тактов процессора чем при SMT и HT.
Специально нигде сильно не углублялся, чтобы не усложнять теорию, просто описал основные принципы работы. А если углубиться в тему, то там еще вылезет кучу специфичных вещей для ОС и конкретной версии ядра… Если бы вы внимательно читали статью, то поняли бы, что речь не совсем про планировщик, а про Core Scheduling… Условно вы предлагаете в автошколе учить водителей, тому на какие контакты приходит сигнал зажигания, какая микросхема как работает, как паять контакты, что где-то там должен быть цифровой сигнал определенной формы и тогда автомобиль заведется. Когда можно просто дать ключи, объяснить, как завести, проверить уровень бензина в баке и все. Зачем водителю знать, как устроен двигатель внутреннего сгорания на инженерном уровне? Если ему достаточно знать, что есть бензин, свеча, свеча воспламеняет бензин и толкает поршень.
Мы не будем углубляться в эту тему слишком глубоко, так как это тема отдельной статьи. Но вы всегда можете найти комментарии и пояснения к коду, в файле: include/linux/sched.h, и изучить эту тему самостоятельно. Умение читать исходные коды ядра, является очень важным навыком для каждого разработчика, который хочет углубиться в программирование ядра Linux. Часть полезной информации также можно найти в официальной документации ядра Linux — Scheduler, но всё же лучше смотреть исходные коды ядра.
у меня не было цели максимально достоверно донести, как работает вытесняющая многозадачность, если углубляться в тему там еще много нюансов. Это тема отдельной статьи. Наоборот цель была передать человеку незнакомому с устройством ОС максимально просто смысл происходящего в ядре ОС. Моя задача не писать сложным языком о сложных вещах, моя задача уменьшить разрыв в знаниях у специалистов и показать, что в реальности все очень просто.
Нет. Например, если происходит кэш-промах при обращении к данным, то процессору приходится обращаться к памяти, а это — достаточно долгая операция (сотни тактов), за время выполнения которой все выбранные с опережением независимые от инструкции, обращающейся к памяти, инструкции успевают исполниться и исполнительные устройства процессора в результате простаивают. Планировщик ОС при этом не получает никакого уведомления: все это происходит для него прозрачно (да и не сможет он на это эффективно среагировать).
А вот наличие второго потока выполнения для другого логического процессора в физическом процессоре с поддержкой HT позволяет в данном примере загрузить эти простаивающие исполнительные устройства физического процессора (если, конечно, этому потоку тоже не понадобится вскоре обратиться в память за содержимым, которое остутствует в кэше).
Строго говоря, HT сама по себе в переключении потоков операционной системы в планировщике не участвует. Она просто представляет планировщику ОС физический процессор как два логических процессора, на каждый из которых ОС назначет по одному потоку выполнения. Огрубленно ( если не обращать внимание на детали, что современные ОС знают о логических процессорах и принимают меры, чтобы не снизить производительность их неправильным использованием), ОС работает с логическим процессом HT так же как с физическим ядром.
Мною про это было написано. Вы сами же что-то надумали, и сами же ответили себе…
WASD1 спасибо за ваше гениальное разъяснение претендующее на нобелевскую премию. Процессор не работает в категориях миллисекунд, он работает в категории тактов и инструкций процессора. Вы еще пытаетесь переложить ситуацию со 100% загрузкой процессора, на задачи, когда один поток уснул и работает другой поток. При 100% загрузке нет никакого преимущества и RT задачах тоже. И вы читали статью не внимательно, мною было сделано замечание на эту тему в статье. Читайте на здоровье www.cs.unc.edu/~anderson/papers/ecrts19d.pdf
Характер многозадачности (кооперативная или вытесняющая) и политика планировщика (простая очередь — FIFO, приоритетная очередь или ещё как) — это две независмые характеристики.
Да так и есть.
К примеру, в классической системе с кооперативной многозадачностью — MS Windows 3.х — была функция DirectedYield, позволявшая передать управление из текущей задачи указанной задаче.
Хоть у меня была 3.11 не знаю, что там было.
HT был введен с целью наиболее полно задействовать все функциональные блоки ядра, которые там есть самые разные — обычные вычисления, вычисления с плавоющей точкой и т.д.
Они без этого все задействованы. Так что тут вы не правы. Как раз дело в шедулере, что переключения через OC затрагивают суммарно больше времени и процессорных тактов.
А потому, для таких систем (например, серверов MS Exchange) включать HT не рекомендуется — выигрыш от задействия разных функциональных блоков не оправдывает потерь на диспетчеризацию для дополнительных ядер.
Это уже особенность Windows c его более микроядерной архитектурой. В Linux же используется монолитное ядро.
WASD1 ссылок нет, вполне логичная интерпретация. Выше уже был дан ответ, почему накладные расходы на переключение выше при использовании средств ОС. И в статье есть картинка иллюстрирующая это, похожие картинки есть в интернете по запросам Hyper-Threading, Intel HT, Simultaneous Multithreading, AMD SMT. Можно добавить еще, что в случае вытесняющей многозадачностью с таймером происходит прерывание, а все прерывания, как нас раньше учили самые дорогие операции для процессора. А в случае кооперативной многозадачности, мы можем не дождаться, что поток нам даст управление т.к. он должен делать это вручную, и при этом может простаивать. В случае с HT и SMT работает простой принцип если конвеер процессора простаивает происходит автоматические переключение на симметричный поток. Для понимания его принципа работы 99% людей этого более чем достаточно. Это все есть на картинке, где показан принцип работы. Могу предположить, что еще предсказание переходов лучше работает при HT и SMT, и отсюда тоже чуть лучше будет производительность. Если человек не занимается слишком низкоуровневым программирование, и низкоуровневой оптимизацией кода или производством процессоров, глубже нет смысла углубляться.
LynXzp у меня не было цели максимально достоверно донести, как работает вытесняющая многозадачность, если углубляться в тему там еще много нюансов. Это тема отдельной статьи. Наоборот цель была передать человеку незнакомому с устройством ОС максимально просто смысл происходящего в ядре ОС. Моя задача не писать сложным языком о сложных вещах, моя задача уменьшить разрыв в знаниях у специалистов и показать, что в реальности все очень просто.
13werwolf13 может и так. Просто у арча самые удобные для чтения скрипты сборки и нравится как сам дистрибутив устроен, но честно раньше я не ожидал, что там мейнтейнеры р*дяи, и тоже в скриптах сборки много грязи. Я им даже патчи на блюдечке преподносил для нескольких пакетов, чтобы они взяли и обновили зависимые пакеты. Все дистрибутивы это сделали, а они там что-то телятся, и многие совсем не умеют читать баги в астриме и писать патчи. Лично перерабатываю каждый скрипт сборки, смотрю багрепорты, оптимизирую код сборки, удаляю костыли времен царя гороха, где-то добавляю свои самопальные патчи, где могу сам решить проблему. Переход для меня не имеет смысл, уже на пути создании своего дистрибутива. В день просматривают не мало багрепортов и по объему написанных патчей RedHat впереди всех, больше всего багов они закрывают, но скрипты сборки тяжелые у них. Насчет универсальной сборки под arch, redhat, debian это не сложно сделать, все собирается в clean chroot просто разный упаковщик пакетов, главная проблема, что везде по разному именуются зависимости, вот это думаю они не смогли решит, иначе пакет будет сразу в себе все зависимости содержать, чтобы не ломать его работу.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
То есть, первый ответ Apple, в котором они признали проблему после получения видео с демонстрацией, вы не заметили случайно или притворяетесь шлангом в попытках отстоять свое мнение?
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Кто действительно разбирается, тому вполне достаточно идеи, описанной в статье для объективной оценки подобного вектора атаки.
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Для того, чтобы оценить вкус молока, не обязательно быть коровой, которая его производит.
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
Какого уровня? Из статьи даже не понятно были ли уязвимость на самом деле, и куча воды с размышлениями в сферическом вакууме. За такие уязвимости никогда не платили. Судя по статье, из Apple ему готовы были заплатить довольно приличную сумму за то, что даже уязвимостью нельзя назвать. И не была проведена успешная атака, и еще главное у человека совсем туго с комбинаторикой. Статья просто хайповая, не более того… И кто действительно разбирается, понимает, что статья это полная вода, и сложность атаки значительно сложнее чем написана в статье и за такую «уязвимость» $18000 это переплата с лихвой. Такую уязвимость ни одна уважающая себя security компания не купит. Сколько уязвимостей вы нашли сами и продали, чтобы рассуждать, что заплатили мало и это плевок в лицо?
ЧСВ у автора в статье просто зашкаливает. Так и не была показана успешная реализация атаки, куча теоретических рассуждений в сферическом вакууме, и много текста о том какой автор молодец… В конце убило, что автор отказался от вознаграждения в $18000, ведь он такой молодец и достоин минимум награды в $100000, а лучше в $250000. Не говоря про то, что много воды.
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...
@SnikeMK причина совсем в другом, причина в накрученных статьях, и программе поощрения авторов. С одной стороны это хорошо платить за хорошие статьи, но к сожалению получается так, что это наоборот поощряет не честную игру и поток шлаковых статей. Выгоднее писать плохие статьи и накручить, с этого живут команды авторов и разные конторы предлагающие услуги написания статей. На этом на днях поймали очередную компанию на хабре и она сильно просела в рейтинге. Увы, но качественные статьи просто тонут в общей массе и не набирают нужного количества голосов, про это уже указывал редактору RU_VDS, что нужно вводить лучшую фильтрацию статей, они платят за статьи деньги, и очень много статей просто не стоят тех денег, что за них платят. Плюс на накрученные статьи даже невозможно возразить, и иметь критическое мышление, надо быть "бараном" и засунуть свой опыт себе в одно место, иначе тебя сеткой ботов заминусуют моментально, так как критиковать безграмотных авторов не положено, и хабр уже не лучшая ИТ площадка, а форум домохозяек. Не реально конкурировать, когда многие играют не честно. Поэтому уже много лет назад произошел отток грамотных авторов и более грамотной аудитории. Про деградацию хабра уже писали везде где можно, такие компании как майл.ру которые раньше были в топе хабра и много писали, уже практически не пишут. Честно говоря когда хабр был в управлении маил.ру такого беспорядка не было, все началось после возврата проекта автору хабра и слияния всех площадок типа Geektimes в одну.
@Drag13 с разработчиками v8 как раз согласен, но чаще всего это просто не грамотный код, а не размер. Как раз после того как почитал разработчиков v8 начал внимательнее относится к стилям и JS коду. Кстати могу предположить, что там такое длинное время AOT это оптимизация больших и медленных библиотек типа jquery. В движке v8 есть специальные оптимизации для всех крупных JS библиотек, лично давно уже не использую сторонние библиотеки кроме vue, react и angular т.к. большая часть из них очень-очень медленные. Даже десяток строк кода может замедлить отрисовку, банально когда стили в рантайме обновляются не пакетно, а каждый стиль изменяется отдельно и тригерит перерисовку.
yield() или sleep() это совсем другой случай, про это мной нигде не было написано. Поток даже может не вызвать yield() или sleep(). Ваши знания как раз видимо и spin loop ограничены…
И вы упустили самый главный момент, что yield() или sleep() займет суммарно значительно больше тактов процессора чем при SMT и HT.
Специально нигде сильно не углублялся, чтобы не усложнять теорию, просто описал основные принципы работы. А если углубиться в тему, то там еще вылезет кучу специфичных вещей для ОС и конкретной версии ядра… Если бы вы внимательно читали статью, то поняли бы, что речь не совсем про планировщик, а про Core Scheduling… Условно вы предлагаете в автошколе учить водителей, тому на какие контакты приходит сигнал зажигания, какая микросхема как работает, как паять контакты, что где-то там должен быть цифровой сигнал определенной формы и тогда автомобиль заведется. Когда можно просто дать ключи, объяснить, как завести, проверить уровень бензина в баке и все. Зачем водителю знать, как устроен двигатель внутреннего сгорания на инженерном уровне? Если ему достаточно знать, что есть бензин, свеча, свеча воспламеняет бензин и толкает поршень.
Мною про это было написано. Вы сами же что-то надумали, и сами же ответили себе…
Да так и есть.
Хоть у меня была 3.11 не знаю, что там было.
Они без этого все задействованы. Так что тут вы не правы. Как раз дело в шедулере, что переключения через OC затрагивают суммарно больше времени и процессорных тактов.
Это уже особенность Windows c его более микроядерной архитектурой. В Linux же используется монолитное ядро.
В принципе ничего, просто будут дороже переключения контекста. Если взять вытесняющую многозадачность, то там используется таймер, по которому он запускается, т.е. до запуска таймера будет простой процессора. А в случае с кооперативной многозадачности мы должны ждать пока поток сам передаст управление другому потоку. Процессор же может моментально выполнить два потока, когда один поток простаивает и когда конвейер процессора пуст. Вычислительный конвейер
@dlinyj Спасибо за отзыв.
Вроде себя за профессионала, как автор статьи выдаете, а даже не понимаете банальных вещей, что скрины легко подделать. Тогда резонный вопрос, где видео демонстрации, которое вы упоминаете?
Правда? В таком случае, такие идеи озвучивались далеко до автора, так же как к примеру sql injection. Это не более чем абстрактный класс атак. Автор статьи ни делал никакого открытия, и не показал реализацию атаку. С таким же успехом можно сделать статью, как вы нашли sql injection на сайте google. И что они вам в переписке отказывают в выплате 1 миллиона долларов. Или вы нашли вместо sql injection, не раскрученную ошибку от sql сервера, но написали разработчикам, что у них там sql injection и у них серьезные проблемы с безопасностью. Вы разницу не понимаете?
Вы сами поняли, что написали? С каких пор у вас сказочные фантазии, что коровы оценивают вкус молока? Такие же фантазии, что автору плюнули в лицо и не оценили его работу?
"Радикальный — DPI: влезать в каждый пакет, анализировать шаблоны трафика, выявлять протоколы по статистическому анализу пакетов."
Увы, но уже с этим встречались в прошлом. В 2010 году когда работал в одной крупной компании, нас интернет провайдер уведомил об одностороннем изменении договора и VPN сеть объединяющая несколько офисов в один момент резко перестала работать. Т.е. об изменении условий договора мы узнали уже постфактум. Суть изменений была такова, что если раньше мы им платили круглую сумму, то теперь за использование VPN через их каналы связи, мы должны им платить круглую сумму умноженную на 3, и они режут теперь всем VPN трафик. Стоить заметить, что не через выделенный VLAN, а именно через сеть Internet. Переговоры не привели к успеху, поэтому послали их в дремучий лес и сменили провайдера.
В середине 2000-х с уходом эры dual-up, многие провайдеры ради экономии трафика и увеличения прибыли любили заворачивать весь http трафик на свой тормозной кэширующий прокси сервер. Благо с https это так просто не прокатит, но никто не защищен, что кому-то в руководстве взбредет в голову запретить весь https и vpn трафик ради "общей безопасности"...
@SnikeMK причина совсем в другом, причина в накрученных статьях, и программе поощрения авторов. С одной стороны это хорошо платить за хорошие статьи, но к сожалению получается так, что это наоборот поощряет не честную игру и поток шлаковых статей. Выгоднее писать плохие статьи и накручить, с этого живут команды авторов и разные конторы предлагающие услуги написания статей. На этом на днях поймали очередную компанию на хабре и она сильно просела в рейтинге. Увы, но качественные статьи просто тонут в общей массе и не набирают нужного количества голосов, про это уже указывал редактору RU_VDS, что нужно вводить лучшую фильтрацию статей, они платят за статьи деньги, и очень много статей просто не стоят тех денег, что за них платят. Плюс на накрученные статьи даже невозможно возразить, и иметь критическое мышление, надо быть "бараном" и засунуть свой опыт себе в одно место, иначе тебя сеткой ботов заминусуют моментально, так как критиковать безграмотных авторов не положено, и хабр уже не лучшая ИТ площадка, а форум домохозяек. Не реально конкурировать, когда многие играют не честно. Поэтому уже много лет назад произошел отток грамотных авторов и более грамотной аудитории. Про деградацию хабра уже писали везде где можно, такие компании как майл.ру которые раньше были в топе хабра и много писали, уже практически не пишут. Честно говоря когда хабр был в управлении маил.ру такого беспорядка не было, все началось после возврата проекта автору хабра и слияния всех площадок типа Geektimes в одну.
@Self_Perfection ответил вам в личных сообщениях.
@Aldrog если не сложно опишите подробнее ошибки в личном сообщении.
@Drag13 с разработчиками v8 как раз согласен, но чаще всего это просто не грамотный код, а не размер. Как раз после того как почитал разработчиков v8 начал внимательнее относится к стилям и JS коду. Кстати могу предположить, что там такое длинное время AOT это оптимизация больших и медленных библиотек типа jquery. В движке v8 есть специальные оптимизации для всех крупных JS библиотек, лично давно уже не использую сторонние библиотеки кроме vue, react и angular т.к. большая часть из них очень-очень медленные. Даже десяток строк кода может замедлить отрисовку, банально когда стили в рантайме обновляются не пакетно, а каждый стиль изменяется отдельно и тригерит перерисовку.