и снова (но давайте более теоретически!?) про тормоза с USB-флешкой вопрос

Тогда почему они не используются?

Не могу ответить на твой вопрос, потому что они используются. Если ты хотел спросить «почему они не используются для борьбы с 12309», то я опять же не могу ответить на твой вопрос, потому что 12309 не существует - это просто общий лейбл для «Linux тармазит!!11».

Почему у login и sshd приоритет стандартный и они виснут вместе со всем остальным линуксом?

Ты не мог бы описать, что именно и когда виснет? Даже в этом топике обсуждаются две сильно разные ситуации, приводящие к thrashing.

Хреновые инструменты?

Возможно. Или хреновое ядро (см. ссылку на LWN).

Почти все вышеотписавшиеся — идиоты.

Что значит - «почти»?...

Друзья, не надо ссориться!!!

Я думал, пойнт в том, чтобы _не_ выставлять их вручную.

Любая автоматика нуждается в ручной корректировке время от времени. Странно, что приходится объяснять такие вещи.

Пусть у меня запущен браузер и -jN компиляция кода на крестах (которая вполне может выжрать столько же, сколько и браузер только одним экземпляром g++), и какая задача более приоритетна? Если я смотрю фильм в браузере, параллельно собирая ебилды, то компиляторам я захочу выставить наименьший приоритет. А если браузер просто болтается в фоне, пока я занимаюсь работой над своими сорцами, то компилятор более важен, чем браузер. Система не может узнать это телепатически.

Схема «большой процесс обслуживается в последнюю очередь» работает в том случае, когда у тебя есть четкое упорядочение по размеру (т.е. процессы различаются достаточно сильно)

А это так и есть во многих случаях. Например на моём компе сейчас:

$ ps -eo %mem,rss,comm k +rss | tail -40
 0.1  9764 bash
 0.1  9764 bash
 0.1  9768 bash
 0.1  9768 bash
 0.1  9768 bash
 0.1 10128 bash
 0.1 10336 python3
 0.1 10760 mc
 0.1 11336 mc
 0.1 11352 mc
 0.1 11476 gvfs-udisks2-vo
 0.1 11512 mc
 0.1 12420 udisksd
 0.1 14048 lxclipboard
 0.1 15388 lxsession
 0.1 15520 docker-containe
 0.1 15984 pulseaudio
 0.1 16056 systemd-journal
 0.2 16824 polkitd
 0.2 19908 NetworkManager
 0.2 23220 rainbow-cm
 0.3 24384 journalctl
 0.3 30368 xfce4-notifyd
 0.3 31228 lxpolkit
 0.4 33568 gdb
 0.4 34184 nm-applet
 0.5 41776 stuurman
 0.5 42832 openbox
 0.5 43964 lilyterm
 0.5 45372 dockerd
 0.7 61956 terminator
 0.7 62124 waterline
 1.3 108976 mpv
 2.3 188976 medit
 2.7 221832 Xorg
 4.4 358428 Web Content
 5.0 406548 Web Content
 5.3 428920 Web Content
 7.4 600408 Web Content
13.8 1122868 firefox

Что глядя на этот пример можно сказать? Что Xorg-у надо вручную выставить приоритет повыше, а всё остальное, в принципе, вполне соответствует ожидаемому поведению. Первые кандидаты на thrashing — процессы браузера, затем текстовый редактор и видеопроигрыватель, затем мелкие тулзы графической оболочки, затем всё остальное.

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

rss_prio = f1(uid) + f2(current_rss) + f3(majflt_per_minute);

Где:

f1(uid) = (uid == 0) ? -ROOT_PRIO_BOOST : 0;

f2 и f3 в простейшем случае линейные функции, но более точно можно сказать только в ходе экспериментов.

Даже в приведенных тобой цитатах ничего не говорится о затратах «процессорного времени».

Хорошо. Допустим, я не прав. Приведи правильное, на твой взгляд, определение thrashing, и поясни, как ситуация исчерпания лимита dirty memory активно записывающим на диск процессом (мы же про эту ситуацию говорим, так?) к нему приводит.

Если в этом наборе жаргонизмов и есть смысл, от меня он ускользнул.

он от меня ускользнул

Вот именно.

В этом предложении условно истинным является только последнее утверждение. Thrashing есть, а в D-state висит разве что kswapd.

Я наблюдал другое поведение. Вернусь с пруфами, когда будет время.

Учись, а то пока твой потолок - топить за systemd.

Уж лучше так, чем хамить на форумах. ;)

там есть еще такие ручки:

$ grep . /proc/sys/vm/*sec*
/proc/sys/vm/dirty_expire_centisecs:3000
/proc/sys/vm/dirtytime_expire_seconds:43200
/proc/sys/vm/dirty_writeback_centisecs:500

(Сам помню только про dirty_expire_centisecs. Надо почитать, за что остальные отвечают.)

Если количество грязных страниц не ограничено, то происходит следующее:

Приложение в течение короткого времени запиливает стопицот грязных страниц в кэш, ядро не обращает на это внимания. Через «3000 centisecs» они все разом устаревают, и ядро фризит любой доступ к диску из приложений, сбрасывая все стопицот страниц на диск.

Вот почему эта особенность проявляется не у всех (и у некоторых не проявляется даже без дергания dirty_bytes-ручек), интересный вопрос...

тык ведь получается что ничего другого патчить кроме Файлового Манагера — не нужно? (ни какие другие программы)

а патч к Манагеру и имеется ввиду — «ручная работа»?

Кстати, еще одна крутилка в продолжение:

	/*
	 * In laptop mode, we wait until hitting the higher threshold before
	 * starting background writeout, and then write out all the way down
	 * to the lower threshold.  So slow writers cause minimal disk activity.
	 *
	 * In normal mode, we start background writeout at the lower
	 * background_thresh, to keep the amount of dirty memory low.
	 */

Пусть у меня запущен браузер и -jN компиляция кода на крестах (которая вполне может выжрать столько же, сколько и браузер только одним экземпляром g++), и какая задача более приоритетна? Если я смотрю фильм в браузере, параллельно собирая ебилды

эээ.. прости парень, но вообще-то этот сценарий попахивает извращениями :-) .. серъёзно, не хочу обижать, но кому захочется включать фильм во время компиляций тонн софта?

разговор то ведь начали с того что тормоза во время копирования на медленную USB-флешку — и просмотр фильмов во время копирования туда — вполне нормальный сценарий (и именно фильм не должен тормозить, и веббраузер).

а в случае же ваших компиляций джентушечного-мира — мне кажется безразницы что будет тормозить. пусть это будет хоть рандомно, почему нет?

Есть только два workflow-а: моё и неправильное

Никогда не задумывался, что ты не пуп земли?

Если что, я не гентушник, кстати.

ни когда не задумывался что вначале должен быть удовлетворён хотябы базовый сценарий а уже потом только нужно пытаться удовлетворять охренительно сложный?

(разжёвываю: попытка сразу удовлетворить охренительно сложный: как правило приводит к тому что в итоге оба не удовлетворяются нормально (или вообще ни как))

базовый сценарий

Базовый сценарий:

Сделать так, чтобы на дефолтных настройках ядра (без пердолинга с лимитами и с-группами) следующий кусок непривилегированного говнокода не приводил к мёртвому зависанию системы навечно до аппаратного сброса:

#include <stdlib.h>
#include <stdio.h>

int main()
{
    size_t s = 1024 * 1024 * 1024 * 8.0; /* подставить свой размер ОЗУ */
    size_t i = 0;
    size_t step = 1024 * 4;
    char * p = calloc(s, 1);

    while (1) {
        printf("=> ");
        for (i = 0; i < s; i += step) {
            p[i] = i;
            if (i % (1024 * 1024 * 128) <= step) printf(".");
        }
        printf("\n");
    }

    return 0;
}

разжёвываю

Разжевываю: если ты не понимаешь, что именно мы обсуждаем с tailgunner-ом, следует начать с ознакомления с манами или с вопросов, а не с невежественных претензий.

our background buffered writeback has sucked

В BSD и солярке такого нет, кстати.

Тебе же написали про набор эвристик. И ещё swapness большая улучшает.

В этом предложении условно истинным является только последнее утверждение. Thrashing есть, а в D-state висит разве что kswapd.

Не понял, к какому конкретно кейсу относится эта часть разговора.

В любом случае, это не совсем верно. Если затык вызыван отсутствием свободной страницы, то кроме «позвать kswapd и ждать», ядро умеет еще и direct reclaim из потока, обрабатывающего страничное исключение. Вот и D-state. Если страница есть, но поток ждёт загрузки данных на неё, это опять D-state.

Если затык вызыван сбросом грязных страниц, то просыпается поток writeback (кажется, так зовётся; могу наврать), а не kswapd.

Только вот на виндах, когда копируешь 30 Гигов, на флешку USB 3.0, копирование заканчивается спустя 5 минут.

А вот на линухах, все встает колом, и процесс копирования длится 4 часа (с 16 гб оперативы, с SSD диска на USB 3.0 флешку).

P.S. Если кто-то думает, что это не реальный use-case, то он не прав, потому что это могут быть равки с фотоика (около 700-800 фоток с мероприятия), видео с камеры и тому подобное. И поэтому linux, все еще не готов для десктопа, а хотелось бы им пользоваться, но такие косяки всякий раз дико выбешивают. И это очень печально.

А вот на линухах, все встает колом, и процесс копирования длится 4 часа (с 16 гб оперативы, с SSD диска на USB 3.0 флешку).

Эксперимента ради скопировал 40Г с SSD на USB 3.0 диск. Система (ноут, 8Г памяти) ощутимо лагала, музыка, которая игралась с того же диска, иногда заикалась (несмотря на deadline scheduler), но, естественно, никаких 4 часов и близко нет. Так что не надо проецировать локальные проблемы, реальные или выдуманные, на весь Linux.

Тебе же написали про набор эвристик

«Эвристика» означает, что это в общем случае не работает. «Набор» означает, что выбирать придется администратору.

Учись, а то пока твой потолок - топить за systemd.

Уж лучше так, чем хамить на форумах. ;)

Если ты выбираешь из двух последних вариантов - хреново тебе.

Я думал, пойнт в том, чтобы _не_ выставлять их вручную.

Любая автоматика нуждается в ручной корректировке время от времени. Странно, что приходится объяснять такие вещи

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

Схема «большой процесс обслуживается в последнюю очередь» работает в том случае, когда у тебя есть четкое упорядочение по размеру (т.е. процессы различаются достаточно сильно)

А это так и есть во многих случаях

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А для случая, когда иерархия размера есть, меня интересует, чем твоя схема лучше иерархии memcg (которая должна работать даже в случае, когда иерархии размера нет).

не плохо конечно было бы решить и этот сценарий тоже. но по сравнению с копированием на флешку — твой сценарий выглядет более общим, всё таки

Баг 12309 он же баг с забиванием Dirty кеша. Проявляется при записи на относительно медленный диск больших объемов информации. Например образа на флешку через dd, копирования огромных файлов с SSD на HDD и даже при записи быстрогенерируемых объёмов информации из оперативки на SSD.

В чём механизм возникновения бага? Баг возникает из-за того, что по дефолту значения объёма dirty кеша — /proc/sys/vm/dirty_ratio и минимального объёма при котором начнётся сбрасывание данных на диск (+ скорее всего он же объём единичного куска для сброса на диск когда dirty кеш полностью заполнен) dirty_background_ratio выставлены в лине в 20 и 10 процентов от свободной оперативки. Что достаточно нерационально для многих типов нагрузки. Если dirty кеш полностью заполняется, то линукс, блокирует ВЕСЬ ввод-вывод, на запись и на чтение со всех устройств и ждет пока объём dirty_background_ratio (или возможно некий объем данных пропорциональный этой величине) запишется на диск перед тем как дать всем остальным программам что-то записать или прочитать с дисков.

Проявляется при записи на относительно медленный диск больших объемов информации.

Причем отнюдь не всегда.

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Не знаю насчет «многих», но, в любом случае, меня интересует случай, когда это _не_ так - т.е. когда память расходуется группой близких по размеру процессов. Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»? Моя цель именно обеспечение «интерактивного отклика». Конкретно в случае Linux — обеспечение хоть какого-то отклика. Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно. Достаточно его просто запустить, подождать несколько секунд, затем нажать Ctrl+C — и можно идти пить чай на 10-15 минут. Примерно столько понадобится, чтобы сигнал прерывания дошел «куда надо». Сам понимаешь, если такой процесс запущен не в foreground-е активного терминала, то поможет только аппаратный сброс.

А для случая, когда иерархия размера есть, меня интересует, чем твоя схема лучше иерархии memcg (которая должна работать даже в случае, когда иерархии размера нет).

Она лучше тем, что работает даже если через memcg ничего не настроено или настроено недостаточно. Ситуация, когда кусок непривелигированного кода, работая в системе с умолчательными настройками, приводит к систему к состоянию полного отказа в обслуживании, я не считаю адекватной. Особо высокая нагрузка на вычислительную систему даже в ущерб выполнению любых административных действий должна быть явно назначенной привилегией, а не умолчательным состоянием любого хелло-ворлда. Это всё равно что запускать все процессы с приоритетами реального времени типа SCHED_FIFO и надеяться на отсутствие в них багов и благие намерения разработчика.

Если говорить об эксплуатационных характеристиках, то приоритизация рабочих наборов лучше иерархии cgroups в следующем:

1. Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации. Один и тот же vim, запущенный одним и тем же пользователем в том же самом терминале может быть либо очень важной задачей, если в нём администратор просматривает и правит конфигурационные файлы, и тот работает исправно, или же низкоприоритетной задачей, если в результате бага он выжрал 4 гигабайта и начал по ним активно ходить туда-сюда. Любой процесс, включая и административные, может «протечь» от багов, подвергнуться атаке, быть случайно запущен в такими параметрами или в таком контексте, которые приводят к выжиранию памяти. Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.
2. cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра, и привязанная конкретно к линуксу. При чем подверженная постоянным доработкам и переделкам именно в силу своей запутанности. Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся ею. Потенциально его можно перенести на другие unix-подобные системы для улучшения их эксплуатационных свойств, в то время как унификация механизмов контейнеризации между ядрами вряд ли возможна в обозримом будущем.
3. Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.) Мы можем отрегулировать hard и soft лимиты, swappiness и... кажется, больше ничего. Это значит, что нам придётся велосипедить демон который будет эмулировать приоритеты поверх системы лимитов — какой-то троллейбус из хлеба получился.

https://www.thomas-krenn.com/en/wiki/Linux_Page_Cache_Basics - вот тут немного теории .... (правда для ядер в районе 2.6.32)

http://duartes.org/gustavo/blog/post/page-cache-the-affair-between-memory-and... (ссылка с более подробным описанием, последняя в серии из 3-х статей)

А мне странно, что ты называешь фактическое отключение автоматики для некоторых процессов (выведение их из-под контроля автоматики) «корректировкой».

А что в этом странного?

Я попытался объяснить выше.

Ну да, твоя цель обеспечения интерактивного отклика хорошо ложится на идею «маленькие процессы важенее больших», но в других ситуациях от нее какая выгода?

А какая может быть «другая выгода»?

Тебе виднее. Если никакой другой выгоды (и никакой другой цели) у страничных приоритетов нет, то, наверное, для своей узкой цели они будут работать - в том случае, конечно, если working set trimming тоже будет подчиняться приоритетам. Будут ли они работать лучше, чем существующая система - большой вопрос.

Код, который я приводил выше, в моих тестах приводит к зависанию системы навечно.

Дай ссылку на код. А то выше какой-то персонаж жаловался на то, что у него 16Г копируются 4 часа.

Это всё равно что запускать все процессы с приоритетами реального времени типа SCHED_FIFO

Похоже, да. И что в этом плохого? Если что, внутри SCHED_FIFO есть много приоритетов.

и надеяться на отсутствие в них багов и благие намерения разработчика

А ты в любом случае должен на что-то надеяться (TCB, ага). Как минимум - на ядро и login/DM, в случае сетевой машины - на ядро, SSH и шелл.

Иерархия будучи сформированной, остаётся таковой постоянно, в то время как эвристика выбора приоритетов позволяет системе адаптироваться к ситуации

Веское возражение. Но, с другой стороны, иерархия тоже адаптируется - есть мягкие лимиты.

Пока в системе остаются здоровые средства взаимодействия с пользователем (и в частном случае с — администратором), они должны продолжать работать вне зависимости от состояния других процессов.

Конечно. Но в твоем случае единственный критерий «здоровья» - размер (если не делать ручных настроек).

cgroups — это обширная и запутанная подсистема, плотно увязанная со всеми другими подсистемами ядра,

И что? Я не предлагаю ее хачить. А подсистема VM увязана с другими подсистемами еще плотнее.

Приоритеты рабочих наборов — узкоспецилизированный механизм, принадлежащий одной конкретной подсистеме и ограничивающийся ею. Потенциально его можно перенести на другие unix-подобные системы

Реализация приоритетов будет таким кластерфаком с VM, что ее «перенос» будет написанием заново.

Иерархия — это снова про лимиты, а не приоритеты. (Или там есть приоритеты выделения и перераспределения памяти? Ткни в ман, если я что-то упустил.)

Иерархия - это и про приоритеты тоже.

https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt

«If one of the ancestors goes over its limit, the reclaim algorithm reclaims from the tasks in the ancestor and the children of the ancestor».

и всё-таки — раз уж мы тут пришли к выводу (хотя и не все собеседники пришли к этому выводу, как я понял :)) — что нужно делать правки внутри прикладных программ — файловых манагерах...

...то тут пришла в голову мысль что наверно какие-то программы (из популярных) всё-таки уже написаны таким образом чтобы не пытаться сожирать всю память во время своей работы. :-)

посмотрел rsync (без какие-то особых ключей. например обычное rsync -rlpt --progress -- ....... .......)

вывод: вроде бы её поведение кажется вполне адекватным! :-)

что-то не так с работой usb

автор женщина

Тем не менее к юсб самая главная проблема - общий для всех устройств dirty кэш - отношения не имеет. Из-за этого кэша же кстати не работает ionice.

Править нужно ядро.

Править нужно ядро.

вообще если подумать — ядро понятия не имеет что же на самом деле хочет прикладная программа..

...хочет прикладная она специально засрать всю память своим невыгружаемым дерьмом?

...или же программа забивает память это по ошибке? забывая подождать окончания своей запрошенной операции (копирование очередного кусочка) ?

предлагаешь натянуть на ядро очередную политику «угадывания»?

а программист (который делает прикладную программу) не может чтоль через API сообщить что же он именно он собирается сделать? лапки вместо рук? :-)

Засерает память и очередь io ядро своим кэшем, программы про это не имеют никакого понятия.

ядро делает то что от него просят программы.

когда программы просят записать байты в файл (в файл(!).. в виртуальный файл, а на устройство фшелку) — ядро записывает эти байты в файл.

когда программы просят ядро подождать пока записанные байты файла попадут на устройство флешку — ядро бережно даёт программе это ожидание.

кто виноват что программы не просят ядро то что эти программы хотели бы от ядра? :-) ядро виновато? ядро виновато в том что оно делает то что его просят, а не то что хотят мысленно программисты программ?

Оно не делает. Write() вызывают чтоб писать на диск а не засерать безумно оперативку и io очередь. Fsync() это из другой оперы совсем. Какой смысл в таком кэше, что убивает производительность а не поднимает её? И нужно писать костыли для его обхода.

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

смысл есть — копирование файла с жёсткого диска на USB-флешку (ну или вообще копирование файлов с одного места на другое) — это далеко не едиснвенный сценарий для которого программы используют write() :-)

смотри, у тебя может быть просто совершенно другая программа — например чат-клиент или программа в которой бугалтерские таблицы — для них ведь тоже неплохо если используется кэш при изменении файлов (изменение файлов конфигурации и ведение логов).

ды даже хотябы обычный web-браузер который запоминает свои куки!

полно всяких программ существуют — и почти все они использутю write() для каких-то своих целей :-)

а если уж какая-то программа решила заняться именно задачей «копирование пользовательских файлов» — то наверно разработчик должен осознавать какой именно прогресс он отображает на экране в момент того когда меняет позицию на progressbar :-)

...

то есть, что я имею ввиду — «копирование пользовательских файлов» это самый редкий сценарий для которого вызывается write() на файлах . а чаще всего оно делается другими программами для чего-то другого.

не хочешь же ведь ты изменить ядро таким образом, чтобы теперь ядро стало хуже работать для всех ДРУГИХ сценариев (которых большенство!), но при этом зато улучшило бы своё поведение лишь на одном частном случае «копирование пользовательских файлов» (ну и да, плюс на случае выше — и снова (но давайте более теоретически!?) про тормоза с USB-флешкой вопрос (комментарий) — незнай конечно только какой умник захочет такое запускать :)))..

Сказать-то что хотел? Я не предлагал убирать кэш полностью, а починить его, чтобы его объём был вменяемый, чтобы реальная учитывалась скорость записывающего устройства, чтобы отдельное устройство не могло единолично его выжрать полностью, чтобы на ядерный writeback распространялся ionice и т.д.

Пруфы на ухудшение есть? И каким образом такой сломаный кэш вообще где-то помогает по-твоему?

Пруфы на ухудшение есть?

да :-) . в твоих словах прям:

чтобы отдельное устройство не могло единолично его выжрать полностью

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

при этом память свободна, а всё равно не используется — из-за лимитов (как ты называешь их тут «вменяемыми».. однако вменяемость вменяемости рознь в зависимости от сценария)

И каким образом такой сломаный кэш вообще где-то помогает по-твоему?

выше написал же — во всех остальных ситуациях. когда программа пишет что-то в свои заветные файлы. все сценарии кроме сценария копирования файлов с одного места на другое.

помощь заключатеся в том что пишется в оперативную память а не напрямую в диск.

память расходуется по максимому, поэтому поизводительность остаётся хорошей до последней возможности

Про /sys/class/bdi/*/max_ratio ещё никто не вспомнил?

Про /sys/class/bdi/*/max_ratio ещё никто не вспомнил?

если выставить для USB-флешки это в значение 20 (вместо 100) — то будет работать именно то о чём хочет этот последний аноним?

или опция чисто декоративная?

user_id_68054 Память не бесконечная, если нижележащее устройство не успевает записывать, кэш просто быстро забьётся и всё встанет колом. А если справляется, достаточно маленького кэша.

Dirty кэш отнимает память, которая могла быть занята кэшем на чтение или самой памятью программы, что и вызывает обсуждаемые реальные тормоза, а не теоретические. Его нельзя просто сбросить, если эта память вдруг окажется нужна а придётся дождаться когда он запишется.

Может тогда как раз в этом случае писать приложения по-нормальному не блокируя всю программу при записи на диск? И не удалять гланды через зад записывая данные на диск, ожидая что те окажутся в оперативной памяти, а сразу их там держать.

post-factum У меня max_ratio не работает, чяднт?

Может тогда как раз в этом случае писать приложения по-нормальному не блокируя всю программу при записи на диск? И не удалять гланды через зад записывая данные на диск, ожидая что те окажутся в оперативной памяти, а сразу их там держать.

тоже вариант :-)

то есть ты предлагаешь политику Ядра, которая бы сделала бы сложнее написание программ которые делают что-то полезное (интерактивное) — но приэтом упростило бы написание программ для копирования файлов. :-)

это да — вариант! почему-бы и нет.

но я бы если чесно, лучше бы выбрал бы ядро которое — усложнило бы задачу для программистов занимающихся копированием файлов, но упростило бы написание полезных интерактивных программ.

Ну тогда представь что пользователь решает открыть вторую программу и ему приходится ждать пока нагаженнное в оперативку допишется.

уже не важно завис

Ты точно не из разработчиков ядра? У нас тут многозадачная ос или что?

ты предлагаешь

Я предлагаю ядро, которое не подвержено DoS от записи достаточного объёма гифок с котиками.

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

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

почему нельзя?

если вдруг на одну минуточку количество write()-событий уменьшилось то можно успеть записать очередь на медленный диск! (говоря про интерактивные программы, а не про копирование файлов)

А если вдруг нет? Предсказуемость важнее, пусть и будет чутка помедленнее.

Я предлагаю ядро, которое не подвержено DoS от записи достаточного объёма гифок с котиками.

не подвержено DoS — это плюс. я согласен. (есть правда проблема в том что DoS-вектора атак останутся — просто ты убрал лишь один из них. делать DoS находясь уже на локальном комьпютере — это слишком уж много вариантов как можно)

DoS от записи достаточного объёма гифок с котиками.

нет, тут не согласен — мы ведь выяснили что просто программу для копирования гифок с котиками нужно переписать подругому, чтобы она не создавала DoS-атаков..

А если вдруг нет? Предсказуемость важнее, пусть и будет чутка помедленнее.

ну тогда всё к чёрту — не справился комп — значит это бесплезный кусок железа.

если мы ограничим файловый кэш — то это может вызвать довольно сильное замедление а не чутка помедленнее. увеличение файлового кэша очень уж оказывает положительный эффект (на интерактиыные программы). все файлы будто бы внутри оперативной памяти — очень приятное ощущение для пользователя.

именно поэтому мы идём на такой риск.

твоя предлагаемая политика Ядра — разумеется тоже позволит писать быстрые интерактивные программы. но очень сильно усложнит их (в случае когда мы действительно захотим писать их быстрыми, не мирясь с притормаживаниями)

программу для копирования гифок

А если это твой любимый браузер их в кэш пишет?

то это может вызвать
очень сильно усложнит

Ну так пруфы будут? Где-то слышал, что в венде кэш записи 16мегабайт, что-то миллионы хомячков не жалуются и даже кроссплатформенные с линуксом программы норм работают.