Сделаем Windows медленнее! Часть первая: файловый доступ

[Koneru]

А какая реакция ОС на подобное поведение процесса? Что произойдет при увеличении буфера до больших размеров(с с# нет опыта)? При достижении критических значений что произойдет, система упадет или остановит опасный процесс?

[tangro]

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

[Koneru]

Спасибо за конструктивный ответ. Также интересует, существует ли максимальный размер буфера?

[tangro]

В документации написано на счёт размера. Формально — int, на практике наверное упрётся и в какую-то меньшую величину.

[datacompboy]

Эм… «You can set the buffer to 4 KB or larger, but it must not exceed 64 KB». А давно приписка о максимуме появилась?

[Goodkat]

А не связана ли эта проблема с патчами для Meltdown?

[mvy]

Зачем человека заминусовали? Да, проблема в не патчах, но добавление KPTI существенно затронуло менеджер памяти Windows. Вполне нормальное предположение, что это регресс, особенно учитывая эпичное фиаско с Windows 7.

[Ghool]

Очень круто, спасибо!

[Koneru]

Кстати, я вот вспомнил что какое то особое создание подпроцесса(не вспомню как делается средствами С++) может грузить ОЗУ, при этом не будет понятно каким процессом. Так например, VirtualBox с запущенной ОС, выделяет ей ОЗУ, и при этом, если не знать про это, непонятно кто так много потребляет.