Стоит озадачиться выяснением того, как работает кэширование в современных многозадачных системах, ну или хотя бы озвучить свои критерии эффективности.

buff/cache -- это не только буферы, но и кэш; если зачитанные в ОЗУ под исполнение приложения (или сервиса) страницы сразу освободить, то повторный запуск потребует повторного зачитывания с соответствующей ФС, поскольку кэш уже эффективно сменеджерили в пользу отчётно-пустой памяти.  Выбросить кэш на чтение как раз недолго, это вот dirty pages -- более дорогая по времени штука.

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

Вот с localhost, который с месяц назад перезагружался и работает в т.ч. сборочным узлом e2kv6:

e1601:~> free -m
               total        used        free      shared  buff/cache   available
Mem:          257588        3085       80445       38334      174057      214110
Swap:          28501           0       28501

То, что формально свободна треть памяти -- скорее показатель того, что working set в целом устоялся, а основные локальные операции ввода-вывода проходят вообще на tmpfs.

Вот с аналогичной системы в домашнем применении (три с лишним месяца аптайма
и несколько другой характер нагрузки, сильно меньше включающий tmpfs):

e16c:~> free -m
               total        used        free      shared  buff/cache   available
Mem:          128797       12883        9708        2470      109823      115913
Swap:              0           0           0

Здесь картина уже более классическая.

В целом предлагаю опираться на понятие working set -- того объёма кода и данных, который должен постоянно размещаться в ОЗУ для собственно работы, а не свопинга; размер ОЗУ должен быть, соответственно, не меньше этой величины.

Смотреть на потребление памяти приложениями в этом разрезе может помочь утилитка smem из одноименного пакета; обратите внимание, что по top сложно учесть на глаз эффект разделения памяти разделяемыми библиотеками (та же libc замаплена, гругря, один раз, а не по штуке целиком на каждое связанное с ней приложение), даже понимая, что смотреть стоит на RSS (resident set size), а не VIRT (хотелки софтинки).

Если Вы пытаетесь запихать Альт Образование непременно с KDE на машинки с 4 Гб памяти, при этом держа по десятку вкладок в браузере -- увы, тут и zram не шибко поможет с аппетитами нынешних браузеров; надо устанавливать в варианте полегче (Xfce) и смотреть, что лишнего грузится, чтоб поотключать.  Если памяти и того меньше -- лучше брать дистрибутивы, современные используемому железу (и я бы поправил по этому поводу циферки на http://altlinux.org/education), или переводить такие машинки в тонкие клиенты, если есть где крутить приложения.

В общем, это не баг, по крайней мере в таких формулировках.  Чтобы сделать багом, надо очень многое конкретизировать -- железо (хотя бы объём ОЗУ), задачи (хотя бы в объёме текстовых снимков экрана top), что крутили самостоятельно (тот же /proc/sys/vm/swappiness можно потрогать и забыть, а крайние потом "разрабы").

PS: если очень хочется почистить кэш -- см. что-нить по словам вроде linux free memory swap cache faq, например, http://losst.pro/kak-osvobodit-pamyat-linux

Переоткройте с доводами, если потребуется.