> и прекрасно представляю, о чем идет речь. ARC имеет преимущество только перед ядрами младше 2.6.26, в 2.6.26 (или в 2.6.25 - точно не помню) реализовали механизм Split LRU, который, в общем-то, и есть примерно то же самое, что применяется в ARC, только без изменения самого механизма замены страниц.

Мне кажется не представляете. К слову в EL6 (2.6.32+) страницы из ext4 buddy cache вымываются аж в лет под активным чтением - что генерит тонну 4k чтений, по простейшим workload - чтение файла размером больше RAM кусками по 1М в 32 потока. Вот такой он LRU - собственно если это убрать - то это уже не LRU будет.

> Точнее - солярка скипает page cache при обращении к ARC, используя page cache только для страниц приложения. Сделано было из-за того, что механизмы солярки не позволяли нормально организовать zero-copy между двумя кэшами. *BSD юзают копирование между кешами - на странице нагуляла на лж четко видно, как падает производительность от отсутствия zero-copy.

Нету там copy. ссылки на код а не на какие-то тесты в студию.

> 3. Алгоритм замены страниц покрыт патентом IBM. В связи с чем использовать в приложениях можно только на страх и риск.

Вас не смущает что RCU в ядре покрыт патентами IBM - при том что исключение сделано только для Linux kernel а остальные открытые проекты должны платить роялити за использование этой технологии? как и многое другое. Раз вас смущает - может вы тогда перестанете использовать Linux kernel?

>> просто страницы с данными находятся одновременно в ARC и LRU Кеше
>Пруф в студию - большинство "пейсателей" этот момент обходят стороной во всех презентациях и статьях. "Забывают", видимо.

Пруфа не будет. Это была ~6часовая лекция от архитекторов ZFS которая по определенным причинам не писалась. Там же объяснялось почему ARC лучший алгортим для этого кэша, и почему остальные не подходят.
С математическим обоснованием если что. Математику я не помню - но помню что копирования там не происходит. И не потому что нельзя было сделать zero-copy.

> А доп расходы по памяти это немного другое, это куча служебных структур
> - для того что бы держать COW и версионные изменения.
> Почему этих расходов нет у BTRFS, при сходной (и более высокой) производительности? Архитектура, дружище, архитектура.

У BTRFS другие проблемы как вы помните. Не эфективная балансировка дерева, плохое использование свободного места и тп.. напомнить ? Архитектура такая вот кривая у BTRFS....

> кроме того у него очень затянутый комит изменений на диск -
> И это никак не связано с ARC кэшем который там внутри...
> Взаимоисключающие параграфы.

это вам так кажется.