LINUX.ORG.RU

Ответ на: комментарий от iron

Выглядит намного вкусней чем в linux. Можно ли сделать нормальный zswap без распаковки в обе стороны, чтобы неактивные страницы в сжатом виде уходили в swap-файл?

anonymous ()
Ответ на: комментарий от iZEN

Я не знаю, что такое ARC. Кривость zswap в том, что страницы сжимаются в zswap, и если надо сбросить на диск, то они разжимаются (прикидывается шлангом). При интенсивной работе с свапом, zswap - это дополнительный бесполезный тормоз из-за двойной работы (сжатие-разжатие с нулевым эффектом), если недодумается напрямую сбрасывать на диск. А хочется чтобы был сжатый swap с сжатым кешем в памяти.

anonymous ()
Ответ на: комментарий от iron

mdconfig -a -t malloc -o compress -o reserve -s 512m -u 7q

А теперь сделай вместо swapon newfs, закинь туда хорошо сжимаемые большие файлы (можно dd if=/dev/zero) и удивись тому, что памяти (wired) все равно жрется ровно столько, сколько занимет непожатый файл.

anonymous ()
Ответ на: комментарий от anonymous

Я не знаю, что такое ARC

Это прибитый гвоздями к ядрам Linux и FreeBSD кэш ZFS.

А хочется чтобы был сжатый swap с сжатым кешем в памяти.

Почему не использовать zram? Если он свопится (должен), то будет это делать в сжатом виде.

anonymous ()
Ответ на: комментарий от anonymous

Почему не использовать zram? Если он свопится (должен), то будет это делать в сжатом виде.

Куда будет СВОПиться СВОП в zram? Я вижу бесконечную рекурсию

anonymous ()
Ответ на: комментарий от anonymous

и удивись тому, что памяти (wired) все равно жрется ровно столько, сколько занимет непожатый файл

И что тут аномального? В wired памяти находится все что угодно пока памяти хватает.

iron ★★★★★ ()
Ответ на: комментарий от anonymous

Можно ли сделать нормальный zswap без распаковки в обе стороны, чтобы неактивные страницы в сжатом виде уходили в swap-файл?

Не встречал такого функционала. Скорее всего нельзя.

iron ★★★★★ ()
Ответ на: комментарий от iron

Вот так получилось:

# dd if=/dev/zero of=disk.img count=1024 bs=1048576
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 0.360115 secs (2981663155 bytes/sec)
# mdconfig -u md1 -o compress -o async -f disk.img
# swapon /dev/md1
# swapinfo 
Device          1M-blocks     Used    Avail Capacity
/dev/md1             1024        0     1024     0%
Total                1024        0     1024     0%

iron ★★★★★ ()
Ответ на: комментарий от iron

В то, что задействуется памяти как для несжатого файла.
Неверующие могут сделать file-based "-f foo", записать туда «seq 100500» и дернуть hexdump — содержимое там не пожато.

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

anonymous ()
Ответ на: комментарий от anonymous

выглядело как заглушка «потом мы добавим фунциональность» …

/* Compression doesn't make sense if we have reserved space */

https://github.com/freebsd/freebsd/blob/master/sys/dev/md/md.c#L1355

Наверно нужно убрать -o reserve чтоб сжатие работало.

iron ★★★★★ ()
Ответ на: комментарий от iron

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

// Не freebsd'шник

mironov_ivan ★★★★★ ()
Ответ на: комментарий от mironov_ivan

будет ли освобождаться память занятая этим виртуальным блочным устройством?

Работа Фри с мамятью очень отличается от других ОСей. Фря практически все что грузит в память там и оставляет в виде буферов и кешей до тех пор пока есть свободная память. Как только Free стремится к нолю, кеши к которым обращались меньше всего выбрасываются.

По идеи, с -o noreserve должна память освобождаться. А как оно на практике - хз.

iron ★★★★★ ()
Ответ на: комментарий от iron

less /usr/src/sys/dev/md/md.c Или я туплю или там нет ничего для сжатия. grep MD_COMPRESS /usr/src — задействуется только в md.c и в mdconfig для флагов.

# mdconfig -a -t malloc -o compress -s 512m -u 7
% top 
1301M Wired
% seq 100500000 |dd bs=1m| > /dev/md7                                             
^C0+131090 records in
0+131089 records out
536940544 bytes transferred in 25.095308 secs (21396053 bytes/sec)

% top
 1814M Wired
#mdconfig -d -u7 
% top
1301M Wired

никакой разницы с заполнением «dd if=/dev/urandom».

anonymous ()
Ответ на: комментарий от anonymous

Или я туплю или там нет ничего для сжатия.

Я тоже нихрена не могу понять из исходников. В мане хитро сказано:

             [no]compress
                     Enable/disable compression features to reduce memory
                     usage.
compression features не значит что ко всем блокам в памяти применяется сжатие. В общем, хрен поймешь.

iron ★★★★★ ()
Ответ на: комментарий от anonymous

Зачем разработчикам из iX (а больше никто не работает над ZFS в прошивке для плойкиFreeBSD) его чинить, если можно просто поднять минимальные системные требования FreeNAS с 8 до 16 или сразу 32 Гб? :D

anonymous ()
Ответ на: комментарий от anonymous

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

Еси без петросянства то арк во фре работает. Иногда.

anonymous ()