Мой десткоп без лимитов перестает отвечать в том числе на пинг от простой форк-бомбы

Запросто. Достаточно на любой системе с 12309 в своп залезть.

Если компьютер с плохой системой охлаждения будет долгое время находиться под 100% загрузкой, то даже если он сможет отвечать на пинг, он может элементарно сгореть. И тогда он на пинг отвечать не будет. Он вообще не будет работать ...

сам себя поправлю:
все, что выше канального уровня, нуждается в участии ядра (CPU не совсем корректно сказал)

Сомневаюсь, ибо 100% загрузка проца даже на работе слабо сказывается.

Можешь конечно сам попробывать ибо способов много, cpuburn тот же.

Снова уроки информктики прогуливаем?

На компьютере с 12309 у меня такое было.

Как бы от шедулера зависит.

Я думаю что это зависит от сетевой карты.

Просто надо загружать на 146% :)

Можно ли загрузить CPU настолько, что хост не будет отвечать на пинг?
3 звезды

/0

Если всё работает корректно, то это возможно только на ОС с невытесняющей многозадачностью, типа Windows 9x, 3.1.

16 ядер- E5620 @ 2.40GHz
Intel Corporation 82574L Gigabit Network Connection
LA ~ 2000, idle 0%
Сервер практически мертвый, пинги не теряются.

зависит от ядра ОС и его мнения насчет приоритетности ответов на пинги

Да. Раньше было достаточно во втором гноме на десять секунд зажать PrtScr. Это если машина слабая. Если помощнее — то ближе к минуте.

/0

Никакого деления на нуль. Скорошлюхи и знания - вещи перпендикулярные.

Только путем переполнения памяти. Просто загрузкой процессора этого не добьешься. А если переполнишь память - то запросто.

почему не добъешься? Смотри, для ответа по ICMP требуется участие ядра операционки, т.к. это сетевой уровень. А если, чисто гипотетически представить, что очередь шедуллера настолько переполненна, что очередь обработки сетевых пакетов подойдет только минут через 10, то на это время хост перестанет быть доступным.
ИМХО конечно :)

Очередь шедулера через 10 минут - нереально без переполнения памяти.

Что именно у тебя может сгореть?

А, все ясно...

Он у тебя 4-х камешковый? Если двух - то научись отличать HyperThreading от ядер...

Ни разу не удавалось. Даже при зацикленной задаче реального времени (100% ЦП) однопроцессорная машина отвечает на ping.

Сегодня форк бомбу обсуждали уже.

Попробуй предварительно сделать

cat /proc/sys/kernel/sched_rt_period_us > /proc/sys/kernel/sched_rt_runtime_us

Что это даст? Машина у меня была мертвой - не реагировала ни на что, кроме пинга.

Не смотря на мертвый вид и зацикленность RT задачи, планировщик продолжает исполнение не-RT задач.

1)После увеличения sched_rt_runtime_us кванта под не-RT не остается

2)Если ответ на пинг посылается из softirq или workqueue, то, возможно, они выполняться не будут

После увеличения sched_rt_runtime_us кванта под не-RT не остается

Думаю, в том ядре, которое мы использовали, этой настройки еще не было - она просто не дала бы системе намертво зависнуть.

Если ответ на пинг посылается из softirq или workqueue, то, возможно, они выполняться не будут

Насчет softirq - они и не выполнялись, если не задрать приоритет ksoftirqd. У меня сложилось впечатление, что у ответа на ping есть какой-то fastpath, который полностью исполняется в прерывании.

Думаю, в том ядре, которое мы использовали, этой настройки еще не было - она просто не дала бы системе намертво зависнуть.

А что за ядро, насколько старое?

Насчет softirq - они и не выполнялись, если не задрать приоритет ksoftirqd. У меня сложилось впечатление, что у ответа на ping есть какой-то fastpath, который полностью исполняется в прерывании.

В ответ посылается пакет, и каким образом это делается, зависит от драйвера сетевого устройства. Как разработчику больше нравится

P.S. На старых ядрах throttling'а вообще не было, да

А что за ядро, насколько старое?

2.6.x не позже 2.6.18

В ответ посылается пакет, и каким образом это делается, зависит от драйвера сетевого устройства. Как разработчику больше нравится

Ответ всё равно формируется сетевым стеком, так что посылка делается так, как больше нравится разработчику стека.

В ответ посылается пакет, и каким образом это делается, зависит от драйвера сетевого устройства.

Пакет - посылается ядром. Далее кадры, за которые отвечает как раз драйвер. Тут разные вещи. Ядро может «висеть», а драйвер-модуль еще жить. Поэтому на втором уровне устройства, в рамках одного сегмента сети (бродкаст домена) будут видеть друг друга, но на пинги ответа не будет.

Я часом не троллю? %)

З.Ы. про RT задачи - интересно. Спасибо.

Это вопрос скорее нужно сформулировать так: «Можел ли ядро позволить настолько загрузить проц, что не сможет отвечать на пинги». И тогда нужно уже будет говорить о конкретных версиях ядер.

Это офигенно:
load average: 149.39, 4948.26, 5194.17
Как я ещё могу писáть на ЛОР? Я фигею.

Ср. лоад был load average: 138.73, 15749.10, 68378.37 Аааааа!!!

Пинги не пропадали, если что.

мне както пофиг что там 4 или 2-х

cat /proc/cpuinfo|grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15

LOR такой LOR...

С чего вдруг на вин9х невытесняющая многозадачность?

Я хотел сказать, что не всегда:

«In Windows 95, 98, and Me, 32-bit applications were made preemptive by running each one in a separate address space, but 16 bit applications remained cooperative.»

Они были кооперативными только между собой, всю систему колом всё равно не поставили бы

В win9x драйвер floppy ставил систему раком и куча других действий.

iab

драйвер

Набери в терминале :() { :|:& };: и проверь.