The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



"Релиз ядра Linux 3.18"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз ядра Linux 3.18"  +/
Сообщение от opennews (??), 08-Дек-14, 09:39 
После двух месяцев разработки Линус Торвальдс анонсировал (https://lkml.org/lkml/2014/12/7/202) релиз ядра Linux 3.17. Среди наиболее заметных улучшений: интегрирована файловая система OverlayFS, добавлен системный вызов bpf(), реализована подсистема для создания туннелей поверх UDP, обеспечена поддержка протокола Geneve, добавлена подсистема pvSCSI для Xen, улучшена производительность при обработке интенсивного потока мелких сетевых пакетов.

В новую версию принято около 11200 исправлений от 1300 разработчиков, размер патча - 38 Мб (изменения затронули 9307 файлов, добавлено 485719 строк кода, удалено 355945 строк). Около 47% всех представленных в 3.18 изменений связаны с драйверами устройств, примерно 18% изменений имеют отношение к обновлению кода специфичного для аппаратных архитектур, 14% связано с сетевым стеком, 4% - файловыми системами и 4% c внутренними подсистемами ядра.

Из наиболее интересных новшеств (http://kernelnewbies.org/Linux_3.18) можно отметить:


-  
Дисковая подсистема, ввод/вывод и файловые системы

-  Интеграция (https://lkml.org/lkml/2014/10/26/137) файловой системы OverlayFS (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... разработанной (http://www.opennet.ru/opennews/art.shtml?num=40947) компанией SUSE в качестве более прогрессивной, компактной и высокопроизводительной замены UnionFS (http://unionfs.filesystems.org/) и AUFS (http://aufs.sourceforge.net/), востребованной в Live-дистрибутивах и системах контейнерной виртуализации.  OverlayFS позволяет (https://git.kernel.org/cgit/linux/kernel/git/mszeredi/vfs.gi... создать виртуальную многослойную  файловую систему, поверх доступной только на чтение основы. ФС создаётся из нижнего и верхнего слоёв, каждый из которых прикрепляется к отдельным директориям.

В качестве нижнего слоя, используемого только для чтения, могут применяться директории любых поддерживаемых в Linux систем, включая NFS и другие экземпляры OverlayFS. Верхний слой, который может быть доступен на запись, будет перекрывать состав нижнего слоя, т.е. если файлы дублируются, в итоговой ФС будет виден только перекрывающийся контент верхнего слоя. При этом все записываемые и изменяемые данные будут сохраняться только в верхнем слое, даже если изначально они размещались в нижнем слое ФС, что позволяет использовать одну основу для создания серии одинаковых окружений (контейнеры приложений), гарантировать неизменность базовых данных (гостевые сеансы) или организовать полноценную работу поверх накопителя, не поддерживающего запись (CD/DVD).

-  В сервер NFS добавлена поддержка операции SEEK, определённой в спецификации NFS 4.2 и позволяющей реализовать в системном вызове lseek() для NFS такие опции, как SEEK_HOLE и SEEK_DATA, для выявления пустых областей и блоков данных внутри файла;

-  В F2FS, развиваемую компанией Samsung высокопроизводительную файловую систему для Flash-накопителей, добавлена поддержка атомарных операций записи, позволяющих рассматривать успешное или сбойное завершение серии операций как единое целое. В F2FS также добавлена поддержка операции FITRIM (http://xfs.org/index.php/FITRIM/discard) (discard), для информирования накопителя о неиспользуемых в ФС блоках.

-  В Btrfs внесены (http://lkml.iu.edu/hypermail/linux/kernel/1410.1/01896.html) улучшения в код восстановления повреждённых RAID-массивов, добавлено множество мелких исправлений, проведена чистка кода;


-  
Сетевая подсистема

-  Добавлена подсистема FOU (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... (Foo-over-UDP) для организации тунеллирования различных IP-протоколов поверх UDP. Так же как туннели SSH работают поверх TCP, а GRE и IPIP поверх IP, FOU позволяет создавать туннели, инкапсулируя трафик в пакеты UDP. Необходимость в создании таких туннелей обусловлена предоставлением специфичных механизмов ускорения обработки пакетов, которые некоторые коммутаторы и сетевые карты предоставляют только для протокола UDP. Настройка туннеля осуществляется с использованием netlink и модуля fou. В утилиту "ip" добавлена новая команда "fou", например, для настройки FOU для IPIP  на порту 5555 можно указать: "ip fou add port 5555 ipproto 4", а для создания туннеля: "ip link add name tun1 type ipip  remote 192.168.1.1 local 192.168.1.2 ttl 225 encap fou encap-sport auto encap-dport 5555";
-  Обеспечена (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g... поддержка алгоритма контроля перегрузки TCP DCTCP (http://simula.stanford.edu/~alizade/Site/DCTCP.html) (Data Center TCP), использующего расширение ECN (https://ru.wikipedia.org/wiki/Explicit_Congestion_Notification) для адаптации алгоритма к специфике применения в сетях крупных датацентров, в которых может наблюдаться как передача крупных непрерывных порций данных, требующих максимальной пропускной способности, так и небольших управляющих потоков, требующих минимальных задержек. DCTCP позволяет не только оценить наличие заторов трафика, но и оценить степень загруженности сети;

-  В сетевую подсистему внесены оптимизации (http://lwn.net/Articles/615238/), направленные на увеличение производительности пакетной передачи данных. Изменения особенно заметны при обработке большого объёма мелких пакетов.  Производительность повышена за счёт организации групповых операций блокировки очереди, а также  заполнения/очистки очереди и взаимодействия с драйвером сетевой карты не на уровне отдельных пакетов, а манипулируя порциями пакетов. Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;

-  Добавлена поддержка протокола Geneve (http://tools.ietf.org/html/draft-gross-geneve-01) (Generic Network Virtualization Encapsulation), универсальный протокол инкапсуляции для виртуализированных сетей, отличается большей гибкостью, чем VXLAN, NVGRE и STT, и не зависит от типа инкапсулируемых данных (VLAN, туннели, MPLS и т.п.);


-  
Память и системные сервисы

-  Добавлен новый системный вызов  bpf() (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... предоставляющий доступ к возможностям универсальной виртуальной BPF-машины внутри ядра. Представленный системный вызов представляет собой единую точку входа, мультиплексирующую доступные операции с eBPF. Для организации получения данных из пространства пользователя представлена новая структура для совместного доступа к данным - 'maps'. В код eBPF добавлены (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... функции загрузки и выгрузки программ BPF, работа с которыми производится по аналогии с модулями ядра. BPF-программа представляет собой готовый для выполнения набор инструкций, для проверки безопасности которых используется специальный блок верификации;
-  Сокращено (http://lkml.iu.edu/hypermail/linux/kernel/1410.1/02561.html) время перехода в спящий режим  для систем с большим числом CPU за счёт избавления от задержки в  100ms для каждого CPU перед его остановкой;


-  
Виртуализация и безопасность

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

-  Добавлен драйвер "pvSCSI (http://wiki.xen.org/wiki/Paravirtualized_SCSI)" (Paravirtualized SCSI), позволяющая организовать работу гостевых...

URL: https://lkml.org/lkml/2014/12/7/202
Новость: http://www.opennet.ru/opennews/art.shtml?num=41210

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Релиз ядра Linux 3.18"  –6 +/
Сообщение от Аноним (-), 08-Дек-14, 09:39 
В убунте уже готовы дебы. Надо ставить, например.
Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Аноним (-), 08-Дек-14, 09:39 
Хотя нет. Лучше я подожду отзывов.
Ответить | Правка | Наверх | Cообщить модератору

51. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 14:23 
Я RC гонял. В целом нормально, но в ранних RC были какие-то race-образные заскоки. При том их душили, душили... у меня вроде стало все ок. Но как минимум 1 разработчик ядра утверждает что у него что-то не так - http://www.phoronix.com/scan.php?page=news_item&px=MTg1NjY

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

Ответить | Правка | Наверх | Cообщить модератору

167. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 10:20 
Я тоже гонял, да и сейчас на нем. Переехал на него по нужде, т.к. видюха и вайфай работают вместе только в нем. Под нагрузкой на сетевуху (p2p) вижу kernel panic. Вечерком попробую накатить релизное ядро.
Железки: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter
$ uname -v
#201411252105 SMP Wed Nov 26 02:06:32 UTC 2014
Ответить | Правка | Наверх | Cообщить модератору

204. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 16:29 
> т.к. видюха и вайфай работают вместе только в нем.

Хуже с поддержкой оборудования в новых ядрах становится довольно редко. А я предпочитаю быструю, стабильную и фичастую работу опенсорсного радеона и фиксы btrfs, который я начинаю все активнее применять. Не то чтобы меня там сильно донимали какие-то проблемы, но чтение ченжлогов, бенчи и прочее наводит на мысль что я чаще всего хочу применять новые ядра. А если все-таки что-то работает не так как должно - как раз логично это репортнуть, чтобы по возможности в релизное ядро не попало.

> Под нагрузкой на сетевуху (p2p) вижу kernel panic.

Однако. Если это в драйвер из майнлайна - баг им в багтрекер, имхо. Только бэктрейс не забудьте, в лог ядра как правило все-таки записывается.

> Железки: 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated
> Graphics Controller (rev 0b)

У меня несколько более древний интеграт на ноуте - работает как часики. Вообще лучший из видеодрайверов которые я видел - просто работает, тянет webgl и даже многие 3D игры на средних настройках в разрешении матрицы ноута (относительно скромном). Так что мне ни разу не пришлось зайти в багтрекер ядра по части интеля. Вот амдшникам иногда достается, но они драйвер активно развивают - ожидаемо.

> Adapter

От себя могу заметить что мне больше всего нравится атерос. А реалтек мне как-то не попадался. Да и идея качать торенты по wi-fi мне не нравится. Но как краштест качества драйвеа вайфая - придумано здорово, надо будет тоже так попробовать :)

> #201411252105 SMP Wed Nov 26 02:06:32 UTC 2014

Это что-то типа -rc7? Перед релизом прилетело несколько фиксов, в том числе какой-то подозрительный race condition который мне не нравится "сам по себе" и несколько небольших фиксов графических дров, в том числе и интеловского. Но там относительно немного изменений.

Ответить | Правка | Наверх | Cообщить модератору

227. "Релиз ядра Linux 3.18"  –3 +/
Сообщение от pavlinux (ok), 10-Дек-14, 00:44 
> Переехал на него по нужде, т.к. видюха и вайфай работают вместе только в нем.

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

  

Ответить | Правка | К родителю #167 | Наверх | Cообщить модератору

237. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Аноним (-), 10-Дек-14, 14:49 
> не рабочее железо, чтоб кайф борьбы был более ощутим. :)

Знаешь, павлин, далеко не всегда точно известно например какой модуль беспроводки в ноуте воткнут. Да и вообще, мысль подбирать железо под ось для линя отстала от жизни лет на 10. Большинство железок линем поддерживается нормально. Бывают взбрыки, но в целом оно вот так.

p.s. не отменяет кайфа при заруливании энного бага мешавшего жить :P.

Ответить | Правка | Наверх | Cообщить модератору

3. "Релиз ядра Linux 3.18"  +/
Сообщение от Fracta1L (ok), 08-Дек-14, 09:43 
OverlayFS обещает быть тортищем в сочетании с пакетным менеджером.
Ответить | Правка | Наверх | Cообщить модератору

5. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 09:46 
главное чтоб не глючил как aufs
Ответить | Правка | Наверх | Cообщить модератору

28. "Релиз ядра Linux 3.18"  –4 +/
Сообщение от хайЗдохнеГнидаРуська (?), 08-Дек-14, 12:11 
> OverlayFS обещает быть тортищем в сочетании с пакетным менеджером.

Да, это годная весчь...

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

29. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Аноним (-), 08-Дек-14, 12:19 
можно узнать, что ты собрался с этим делать?
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

30. "Релиз ядра Linux 3.18"  +/
Сообщение от Fracta1L (ok), 08-Дек-14, 12:24 
Можно заворачивать некоторые приложения с их зависимостями в отдельные каталоги и динамически накладывать их на корневую ФС. Например, если приложение требует по зависимости пакет, нужной версии которого нет в репах, или который не может ужиться с уже установленной в системе версией.
Ответить | Правка | Наверх | Cообщить модератору

128. "Релиз ядра Linux 3.18"  +5 +/
Сообщение от anonimouse (?), 09-Дек-14, 03:39 
Аццкий бардак чувствую я, приближается неотвратно он, не найти конца того начала слабым кто поддастся :)
Ответить | Правка | Наверх | Cообщить модератору

198. "Релиз ядра Linux 3.18"  +/
Сообщение от Фанатик (?), 09-Дек-14, 14:46 
В nixos тоже самое, только по другому
Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

52. "Релиз ядра Linux 3.18"  –4 +/
Сообщение от Аноним (-), 08-Дек-14, 14:23 
> OverlayFS обещает быть тортищем в сочетании с пакетным менеджером.

Костылищем. Нормально это делается снапшотами в btrfs.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

75. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Fracta1L (ok), 08-Дек-14, 16:12 
Снапшоты не катят по простой причине: чтобы обновить систему со всеми наложенными пакетами, нужно будет обновить все снапшоты.
Ответить | Правка | Наверх | Cообщить модератору

86. "Релиз ядра Linux 3.18"  +/
Сообщение от ананим (?), 08-Дек-14, 17:19 
Или сделать снэпшот снэпшота.
К тому же можно использовать обе эти фс, что даёт массу плюсов в сочетании.
Ответить | Правка | Наверх | Cообщить модератору

134. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 06:23 
> Снапшоты не катят по простой причине: чтобы обновить систему со всеми наложенными
> пакетами, нужно будет обновить все снапшоты.

Неправда. В нормальном виде это как-то так: перед обновлением делается снапшот. Если обновление приводит к факапу - возвращаем все как было откатом на снапшот. Иначе оставляем новое состояние. Снос снапшотов - в зависимости от жабы на место под хранение старых состояний.

Если хочется снапшотировать более гранулярно - это можно. Но тогда придется и рулить более гранулярно, дергая пачку субволумов. Чудес не бывает - чем более гранулярно хочется рулить, тем больше рукояток придется крутить.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

140. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Fracta1L (ok), 09-Дек-14, 07:19 
К чему ты это пишешь? Вникни в суть нити разговора для начала.
Ответить | Правка | Наверх | Cообщить модератору

166. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:57 
> К чему ты это пишешь? Вникни в суть нити разговора для начала.

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

Ответить | Правка | Наверх | Cообщить модератору

189. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Fracta1L (ok), 09-Дек-14, 13:08 
Ты до сих пор не въехал в суть. Смотри: есть корень, есть пакет_1 и пакет_2. Пакет_1 тянет либу определённой версии, которая конфликтует с версией в корне. Пакет_2 вообще таскает все либы с собой. OverlayFS позволяет оба эти пакета накладывать на корень, при этом наложены будут сугубо пакеты и их либы, остальное будет использоваться из корня.

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

Ответить | Правка | Наверх | Cообщить модератору

205. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 16:37 
> позволяет оба эти пакета накладывать на корень, при этом наложены будут
> сугубо пакеты и их либы, остальное будет использоваться из корня.

А btrfs может при этом сбацать множественные копии корня с произвольной дельтой относительно прародителя. Те же яйца, вид в профиль. Для пущей красоты - отстегнуть их в отдельные контейнеры, раз уж разные окружения нужны. Так админ по крайней мере не сойдет с ума при администрировании всего этого.

> возникнет, когда потребуется обновить систему.

Бардак там возникнет - пакетный менеджер штатно не готов такие вещи отслеживать, да и админ без должного инструментария задолбается разбираться что там где. И сдается мне что самое простое что тут можно придумать - вынести окружение программы в контейнер вместе с ней, если уж такое надо. И далее рулить этим как мини-копией системы/окружения. Такое можно будет рулить как нечто типа группки машин с более-менее обычной копией ОС и пакетным менеджером.

Ответить | Правка | Наверх | Cообщить модератору

217. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Fracta1L (ok), 09-Дек-14, 18:22 
У тебя в голове бардак. Изменение одного снимка никак не затрагивает остальные снимки, и если приложения будут каждое в своём снимке - чтобы обновить систему, придётся обновлять каждый снимок. Снимок целой системы просто избыточен для такой задачи, как ввод в систему стороннего приложения - достаточно снимка самого приложения.
Ответить | Правка | Наверх | Cообщить модератору

79. "Релиз ядра Linux 3.18"  +/
Сообщение от Анонимъ (?), 08-Дек-14, 16:50 
> Костылищем. Нормально это делается снапшотами в btrfs.

btrfs-таки не нужен для этих целей. Пусть федоровцы себе делают с btrfs у себя что хотят и как хотят, это их выбор.

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

129. "Релиз ядра Linux 3.18"  +/
Сообщение от anonimouse (?), 09-Дек-14, 03:41 
из тихого разговора на кухне: ... про системД тоже так говорили ... а оно вона - назад уже не вынуть :(
Ответить | Правка | Наверх | Cообщить модератору

135. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 06:25 
> а оно вона - назад уже не вынуть :(

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

p.s. но вот всяких бсдшно-солярных ни разу не жалко. Что-то монструозный SMF на соляре таких не смущал.

Ответить | Правка | Наверх | Cообщить модератору

4. "Релиз ядра Linux 3.18"  –12 +/
Сообщение от Аноним (-), 08-Дек-14, 09:45 
реверсинженированный nouveau умеет displayport, а radeon нет.
Позор АМД
Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Fracta1L (ok), 08-Дек-14, 10:04 
Зато АМД с сообществом дружит, вот!
Ответить | Правка | Наверх | Cообщить модератору

55. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 14:27 
> Зато АМД с сообществом дружит, вот!

И соообщество давно отвинтило бы им головы если б дисплейпорт не работал. Фаны нвидии такие забавные.

Ответить | Правка | Наверх | Cообщить модератору

77. "Релиз ядра Linux 3.18"  –8 +/
Сообщение от Fracta1L (ok), 08-Дек-14, 16:17 
> Фаны нвидии такие забавные.

Мы хотя бы на словах забавные, а фаны амд забавные в жизни - покупают видеокарты, которые в Линуксе работают как-то нерегулярно.

Ответить | Правка | Наверх | Cообщить модератору

78. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 16:49 
Линус показал животворящий перст нвидиии и всем ее неадекватным фанбоям. С, амд, кстати, проблем под линем нет (открытые дрова), в отличие от зеленого генератора багов.
Ответить | Правка | Наверх | Cообщить модератору

87. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Fracta1L (ok), 08-Дек-14, 17:35 
> Линус показал животворящий перст нвидиии

Думаешь о нём перед сном, наверное?

> С, амд, кстати, проблем под линем нет (открытые дрова)

Три года назад я ставил убунту на ноут с амд-видео - ноут возвращался из сна с чёрным экраном, и тормозила отрисовка. Несколько месяцев назад ставил Минт на другой уже ноут, но с амд-интеграшкой опять - всё то же самое: отрисовка тормозит, если нечаянно отправил в сон - только ребут. Штабильность.

Ответить | Правка | Наверх | Cообщить модератору

90. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 19:14 
Сказки какие-то.
Ответить | Правка | Наверх | Cообщить модератору

132. "Релиз ядра Linux 3.18"  +/
Сообщение от Fracta1L (ok), 09-Дек-14, 04:33 
О, ну если ты так говоришь, то это всё меняет, да.
Ответить | Правка | Наверх | Cообщить модератору

110. "Релиз ядра Linux 3.18"  +/
Сообщение от ritsuka (?), 09-Дек-14, 00:14 
Последний раз такое в 2010 на убунте видел.
Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

139. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 09-Дек-14, 07:19 
> возвращался из сна с чёрным экраном, и тормозила отрисовка.

Это как? Или уж черный экран, или уж отрисовка? Или я чего-то не понимаю?

А так это может быть quirk вполне конкретного BIOS ноута. Такого счастья в биосах немеряно. Наиболее популярные граблы - в управляторах питанием и сном прокостылены и закидоны инициализации после выхода из спячки учтены. Кому надо BIOS после этого дернуть. А кому это смерти подобно. Ну и так далее. У ноутов в плане ACPI на самом деле творится полный пэ. Так что отдельные приветы желающим видеть UEFI на ARM - хотите такой же пэ и там? :) Наверняка там не все модели и все их баги прописаны. Ядро 3.18 правили под какие-то проблемы с попытками передобавить девайс на шине который уже есть, etc. В dmesg при этом вообще что пишется? Есть ошибки, etc? На вот этом релизном кернеле, например?

> - всё то же самое: отрисовка тормозит, если нечаянно отправил в
> сон - только ребут. Штабильность.

Ну как бы если ты намерен пальцевать - ну и фиг с тобой, это ж не у нас проблемы. А если по уму - так стоило бы понять в чем проблема да пнуть амдшников. Если это по их части. Я вот словил проблему с выходом из спячки. Но она оказалась в light-locker'е. И починилась сносом этого подарка от убунтуев и заменой на более приличный локер. Стало зашибись, но GPU там вообще не при делах были...

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

138. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 07:10 
> - покупают видеокарты, которые в Линуксе работают как-то нерегулярно.

Не знаю, мой R9 270 вполне регулярно работает. И довольно нехило шпарит, спокойно вытягивая xonotic с настройками ultra в 2560х1600. И даже вычисления начинают обретать форму - половину известных мне багов там успешно замочили.

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

141. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Fracta1L (ok), 09-Дек-14, 07:28 
А цива пятая работает? Игры в wine?
Ответить | Правка | Наверх | Cообщить модератору

169. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 10:48 
> А цива пятая работает?

Понятия не имею. У меня на самом деле иные приоритеты ;). А относительно мощный GPU... кто ж виноват что слабый GPU не справится с моим монитором даже в Xonotic? А тут как раз амд сделали удачную вундервафлю которая хорошо считает и умеренно кушает и вентиляторми не гудит.

Я не буду настаивать что опенсорсный радеон лучший выбор для геймерских конфиг, потому что как минимум GL 4.x не допилен (MESA 10.4 выйдет без GL 4). Но вообще он тянет довольно тяжелые двигуны, типа демок Unigine, народ на нем играет в нечто типа Dota, а в TF2 он вообще каталист в бенчах фороникса обставил. Т.е. чтобы немного порубаться без особого фанатизма - в большинстве случаев его как ни странно хватит.

...а когда открытый софт с открытым драйвером выдают симпатичную картинку с нормальным FPS, для меня это вполне себе котируется как награда.

> Игры в wine?

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

Ответить | Правка | Наверх | Cообщить модератору

233. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Fracta1L (ok), 10-Дек-14, 05:31 
Как и следовало ожидать.
Ответить | Правка | Наверх | Cообщить модератору

238. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:02 
> Как и следовало ожидать.

Ну еще бы. Я интересуюсь тем что мне интересно и полезно. Цива мне более-менее перпендикулярна. И вайна у меня нет. Кому эти юзкейсы нужны - пусть они и тестируют как это работает и какие там грабли. Мне это если и интересно то только с точки зрения технической валидации - скорость работы, недостающие фичи, etc.

Ответить | Правка | Наверх | Cообщить модератору

103. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Мяут (ok), 08-Дек-14, 22:21 
Вот кстати Грег Кроа-Хартман замечает, что АМД разработчиков Linux поувольняло:
http://www.reddit.com/r/linux/comments/2ny1lz/im_greg_kroahh...

Так что это в некоторой степени - вынужденная мера.

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

136. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 06:35 
> Вот кстати Грег Кроа-Хартман замечает, что АМД разработчиков Linux поувольняло:

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

Ответить | Правка | Наверх | Cообщить модератору

228. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 00:47 
> Зато АМД с сообществом дружит, вот!

:D

Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

53. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 14:25 
> реверсинженированный nouveau умеет displayport, а radeon нет.

С дуба рухнул? Если б амд не умел свой же displayport - это был бы номер!!!

> Позор АМД

Для начала в нуво реклок не работает толком. А получить 15% от производительности блоба - как-то немного ни о чем.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

64. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:51 
http://xorg.freedesktop.org/wiki/RadeonFeature/
да, написано работает.
А звук не работает.
Ответить | Правка | Наверх | Cообщить модератору

66. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 15:02 
> да, написано работает.

Там вообще зачастую обновить забывают некоторое время и оно бывает немного устаревшим.

> А звук не работает.

А звук через display port - довольно узконишевое развлечение, для начала. Обычно display port ставят в нормальные мониторы, где производители считают как-то ниже своего достоинства ставить дежурные телевизионные двухватные бухтелки издающие звук как из унитаза. По поводу чего напнуться на конфиг где это было бы проблемой - нет, ну теоретически наверное можно. А практически я вообще только благодаря этому бухтежу и узнал что через DP оказывается еще и звук можно. Обычно кому надо звук - юзают HDMI, там это громко заявлено и работает. В том числе и у амдшников на большинстве GPU.

Ответить | Правка | Наверх | Cообщить модератору

67. "Релиз ядра Linux 3.18"  +6 +/
Сообщение от Аноним (-), 08-Дек-14, 15:06 
> Обычно display port ставят в нормальные мониторы, где производители считают как-то ниже своего достоинства ставить дежурные телевизионные двухватные бухтелки издающие звук как из унитаза.

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

Ответить | Правка | Наверх | Cообщить модератору

137. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 06:37 
Ну так Display Port актуален в основном для хороших мониторов высокого разрешения. А всякая там бытовуха обычно для начала вообще с одним HDMI идет, без всяких DP. По поводу чего - масштаб проблемы "нет аудио через DP" и "не работает DP!!!111" - очень разный.
Ответить | Правка | Наверх | Cообщить модератору

11. "Релиз ядра Linux 3.18"  –3 +/
Сообщение от Аноним (-), 08-Дек-14, 10:09 
Да, ядро 3.18, а до сих пор десктоп встает колом при интенсивных дисковых операциях. Пускай не так сильно как раньше, но все равно.
Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз ядра Linux 3.18"  +4 +/
Сообщение от ckfdferhfbyt (?), 08-Дек-14, 10:15 
modprobe руки.ko
rm -rf убитый_жд

стояли все 3.18-rc* по очереди ни одного зависона (даже на злочастный lockup rcu* не попал) или тормозов вообще или связанных с io (scheduler deadline)

Ответить | Правка | Наверх | Cообщить модератору

106. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 23:04 
insmod прямые_руки же ))
Ответить | Правка | Наверх | Cообщить модератору

13. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 10:16 
https://www.kernel.org/pub/linux/docs/lkml/reporting-bugs.html
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

18. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от skybon (ok), 08-Дек-14, 10:46 
BFS/BFQ в помощь.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

20. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 11:05 
Включаем виртуалбокс, запускаем в нем что то тяжелое вроде САПР-а (просто пример), отдав ему 4Гб озы. После поработали и сохраняем состояние виртуалки вместо выключения оной. Открытый в хост системе софт встанет колом в первые пять секунд.

Ядро 3.17-3.dmz.1-liquorix-amd64

Ответить | Правка | Наверх | Cообщить модератору

49. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:21 
У Вас intel CPU? А какой чипсет?
Ответить | Правка | Наверх | Cообщить модератору

56. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:28 
> Ядро 3.17-3.dmz.1-liquorix-amd64

1) Это не 3.18?
2) А как насчет нормально отпрофайлить систему? Ну там sysdig запустить, etc? Latency top?

Не, не слышали?

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

85. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 17:16 
Сейчас ядро 3.17.4-1-ARCH. Оперативной памяти 8Gb, свапа нет, диск обычный не ssd, шедулер cfq, /tmp смонтирован как tmpfs. При этом пользуюсь виртуалбоксовскими виртуалками и приложениями требовательными к памяти (например eclipse). При этом никаких проблем во время интенсивных дисковых операций никогда не замечал.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

127. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 03:28 
Медленный диск (читай как 7200 rpm sata) + мало свободной памяти под дисковый кеш = тормоза при дисковых операциях. Всегда. Чудес не бывает.
Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

229. "Релиз ядра Linux 3.18"  –5 +/
Сообщение от pavlinux (ok), 10-Дек-14, 00:49 
> Включаем виртуалбокс, запускаем в нем

Вот только не говорите мне, что я не предупреждал про Vmware - как единственно нормальную виртуалку.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

239. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:03 
> Вот только не говорите мне, что я не предупреждал про Vmware -
> как единственно нормальную виртуалку.

Затвердила сорока якова, одно про всякого.

Ответить | Правка | Наверх | Cообщить модератору

246. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от pavlinux (ok), 10-Дек-14, 15:31 
>> Вот только не говорите мне, что я не предупреждал про Vmware -
>> как единственно нормальную виртуалку.
> Затвердила сорока якова, одно про всякого.

Ёпть, ну жрите дальше кактус! Срать потом ещё сложнее будет.

Ответить | Правка | Наверх | Cообщить модератору

24. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 11:24 
Пресловутый BFS/BFQ ничо не решает в данной ситуации, кстати. Так, больше для успокоения.
Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

31. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 12:36 
Он в принципе ничего не решает, что не могут решить штатные шедулеры
Ответить | Правка | Наверх | Cообщить модератору

58. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:32 
> Он в принципе ничего не решает, что не могут решить штатные шедулеры

Он как правило дает весьма номинальный выигрыш.

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

Лечение очевидно: системное I/O не надо держать там же где и bulk I/O. Поставить под систему быстрый SSD, а под данные - что не жалко (в идеале тоже SSD, если жаба не давит).

Ответить | Правка | Наверх | Cообщить модератору

258. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от skybon (ok), 11-Дек-14, 12:52 
> Пресловутый BFS/BFQ ничо не решает в данной ситуации, кстати. Так, больше для
> успокоения.

Ещё как решает. Если раньше проекты в BOINC (да-да, знаю, это не I/O, а процессор, но пофиг) завешивали десктоп так, что даже мышка была как слайдшоу, то с linux-ck вообще про пресловутые РВ не вспоминаю.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

22. "Релиз ядра Linux 3.18"  +12 +/
Сообщение от rshadow (ok), 08-Дек-14, 11:23 
Так ты в Линукс то ребутнись...
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

35. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Fracta1L (ok), 08-Дек-14, 13:15 
Почему у меня уже давно ничего не встаёт колом?
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

45. "Релиз ядра Linux 3.18"  +18 +/
Сообщение от Аноним (-), 08-Дек-14, 14:09 
> Почему у меня уже давно ничего не встаёт колом?

Это вы к сексопатологу обратитесь :)

Ответить | Правка | Наверх | Cообщить модератору

48. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Плохиш (?), 08-Дек-14, 14:15 
Попробуйте виагру и т.п. попить :)
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

84. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от mihalychemail (ok), 08-Дек-14, 17:15 
> не встаёт

Фотаешь проблемный орган, в рамочку и перевязываешь чёрной ленточкой. Заказываешь духовой оркестр с грустной композицией, пусть сыграет. Одним махом, не чёкаясь, дёргаешь 100 грамм водки (не более!) глядя в рамочку.
Процедуру повторить через 9 дней, затем через 40...

Но выход есть! Берёшь маленький путейский ключик на 65 и вечером, когда стемнеет, идешь на железнодорожную станцию (днём побъют просто) откручиваешь одну гайку и быстро и незаметно домой, накручивать на проблемный орган.
Мощный магнит насаживаешь на цель из нержавеющей стали и под видом магического амулета вешаешь на шею источнику вожделения.
И, о чудо!

> встает колом

Как у молодого. (:  Извините, не сдержался.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

262. "Релиз ядра Linux 3.18"  +/
Сообщение от 1 (??), 17-Дек-14, 01:05 
Брехня, пробовал я все это, не работает :(
Ответить | Правка | Наверх | Cообщить модератору

39. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от botman (ok), 08-Дек-14, 13:45 
> а до сих пор десктоп встает колом при интенсивных дисковых операциях

Предположу что swap не примонтирован или диск|оперативка битые, ещё бывало так с 32-битным ведром на ранних amd64... но это когда было уже... Сейчас на 3.16 стоит btrfs на руте и хомяк под ext4, ничего такого нету.

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

43. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:00 
>> а до сих пор десктоп встает колом при интенсивных дисковых операциях
> Предположу что swap не примонтирован или диск|оперативка битые, ещё бывало так с
> 32-битным ведром на ранних amd64... но это когда было уже... Сейчас
> на 3.16 стоит btrfs на руте и хомяк под ext4, ничего
> такого нету.

У меня то же btrfs стоит, правда везде. Своп выделен и примонтирован. Так же использую zram. Если zram убрать, то вообще будет дубак системе, она частично снимает проблему хотя бы при небольшой нехватке памяти. Если дисковый свап врубается, то все, каюк, сиди, жди, я не дожидаюсь и нередко просто насильно выключаю комп. Но, с тех пор как озы стало 8Гб, эти проблемы не так сильно заметны. Потому, уже не ищу решений (а попробовано их море). В результате всех решений вывод прост, вернее их два 1. Дисковая подсистема в линуксе как то не шибко хорошо работает для десктопа. 2. Своп в линуксе вообще штука жуткая.

Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все старое и точно не помогает, так как проверено.

Ответить | Правка | Наверх | Cообщить модератору

47. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 14:14 
> Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все
> старое и точно не помогает, так как проверено.

Если своп начинает писать на диск... я бы подумал что в системе что-то течёт и забивает всю оперативку

Ответить | Правка | Наверх | Cообщить модератору

65. "Релиз ядра Linux 3.18"  +3 +/
Сообщение от Аноним (-), 08-Дек-14, 14:54 
> У меня то же btrfs стоит, правда везде. Своп выделен и примонтирован.
> Так же использую zram. Если zram убрать, то вообще будет дубак
> системе, она частично снимает проблему хотя бы при небольшой нехватке памяти.

Ну то-есть вы сами себе создали проблему нехваткой физической памяти и потом удивляетесь что своп - очень хреновая и медленная эмуляция опративки? И да, если прога выдавилась в своп - при налете на отсутствующую страницу программа встанет колом пока ядро не достанет ее из свопа. Если это потребует 10 секунд (мало ли на какой флопарь вы там свопились) - значит будете ждать. А куда вы денетесь?

Как сделать реально быструю систему?
- SSD под систему. Жирные данные, если их много можно на отдельный винч вынести. Можно механический. Там если что и будет клинить то только сильно отдельные программы которые эти данные лопатят.
- Достаточно RAM (>=4 Gb) для работы. А если виртуалки надо, памяти >=8Gb, как ни крути.  
- Отрубить нафиг своп.
- Для пущего шика lowlatency ядро можно поставить/собрать.

Система станет турбореактивной. I/O просто не сможет затыкаться на уровне физики в местах где вас бы это напрягло. А потуги полисовать тормозной патефон с магнитными головами где время прогона голов заранее неизвестно и реальную геометрию знает только фирмварь, которая это наружу не скажет - понятно как будет работать.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

69. "Релиз ядра Linux 3.18"  +5 +/
Сообщение от Аноним (-), 08-Дек-14, 15:16 
> А потуги полисовать тормозной патефон с магнитными головами где время прогона голов заранее неизвестно и реальную геометрию знает только фирмварь, которая это наружу не скажет - понятно как будет работать.

Отсюда мораль: планировку очереди отдать AHCI NCQ, а ядерный шедулер взять попроще - noop, deadline, например.

Ответить | Правка | Наверх | Cообщить модератору

142. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 07:33 
> Отсюда мораль: планировку очереди отдать AHCI NCQ, а ядерный шедулер взять попроще
> - noop, deadline, например.

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

Ответить | Правка | Наверх | Cообщить модератору

172. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:04 
Ну так накопитель свою геометрию прекрасно знает, и буфер у него некоторый наличествует. Вот и отдай ему то, что он умеет лучше тебя, делов-то.
Ответить | Правка | Наверх | Cообщить модератору

206. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 16:53 
> Ну так накопитель свою геометрию прекрасно знает,

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

> и буфер у него некоторый наличествует.

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

> Вот и отдай ему то, что он умеет лучше тебя, делов-то.

А у него там фирмвара на проце ограниченной мощности и память ограниченного объема - если ты думаешь что он там мега-логику сможет очень результативно навернуть - это зря. В целом по моим наблюдениям механические диски очень не лю многопоточный доступ. С большим дисковым буфером система может свести кучу мелких записей к нескольким большим и непрерывным. Что хорошо и в плане фрагментации и скорости. И чем жирнее дисковый буфер тем больше возможностей для того чтобы сделать запись более-менее оптимально и не насилуя диск множеством seek во все стороны.

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

Ответить | Правка | Наверх | Cообщить модератору

70. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 15:18 
> Я жалуюсь так, послушать ответы может действительно новое решение нашлось, пока все старое и точно не помогает, так как проверено.

Список "всего старого" в студию!

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

116. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 01:03 
/etc/sysctl.conf

vm.overcommit_ratio = 80
vm.overcommit_memory = 2
vm.dirty_bytes = 8388608
vm.dirty_background_bytes = 8388608
vm.vfs_cache_pressure = 50

помогает отлично. сам страдал много лет, нарыл решение неделю назад, когда надоело смотреть на очередное "сейчас запишу файлики на usb флешку и будет тебе кино и браузер".

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

143. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 07:35 
> смотреть на очередное "сейчас запишу файлики на usb флешку и будет
> тебе кино и браузер".

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

Ответить | Правка | Наверх | Cообщить модератору

170. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 11:45 
Где берут это фантастическое ядро? И почему не починят 12309 в ванильном?
Ответить | Правка | Наверх | Cообщить модератору

171. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 09-Дек-14, 11:52 
> Где берут это фантастическое ядро? И почему не починят 12309 в ванильном?

upd. все ядра с периодичностью обновления 1-2 месяца за последние 10 лет.
я их все пробовал. не на всех записывал на флешку конечно, но в 3.17.4 баг есть, гарантированно приводящий к "сходи кофе попей". вышеприведенные строчки в sysctl.conf лечат проблему полностью.

Ответить | Правка | Наверх | Cообщить модератору

207. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 16:55 
> строчки в sysctl.conf лечат проблему полностью.

Звучит как будто в каких-то случаях аналог 12309 не придушили до конца. Ну то-есть похоже на то что выстраивается большая очередь страниц при тормозном накопителе. А не должна...

Ответить | Правка | Наверх | Cообщить модератору

230. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 00:56 
>> строчки в sysctl.conf лечат проблему полностью.
> Звучит как будто в каких-то случаях аналог 12309 не придушили до конца.

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

Ответить | Правка | Наверх | Cообщить модератору

240. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:17 
> Не придушится он, это архитектурный косяк SATA и вообще любых
> последовательных интерфейсов интегрированных в чипсет.

Ты чего, каркуша? Проиграл войну зеленому змею? Чем тебе архитектура не та?

Если уж архитектурно, последовательный интерфейс от параллельного отличается аж целым "лишним" блоком SERDESа по пути, который из параллельного представления делает в темпе вальса последовательное, ну и обратно. Ну ок, в SATA еще попутно всякое кодирование типа 8/10 делают, но это несколько простых и сравнительно глупых железок.

А я вообще говорил про иное: если ядру надо память - ядро может попробовать забрать ее у дискового кэша. В том числе, инициировав сброс кэша на диск и отъем этих страниц. И если накопитель тормозной а страниц на выжимку много - тот кто память попросил может довольно долго курить бамбук, что и было 12309. Его помнится починили просто затвикав поведение кэша так чтобы для тормозных дисков не было огромных очередей. И у многих недовольных вроде как все стало ок. А тут такое ощущение что подобные по смыслу грабли опять где-то вылезают.

Ответить | Правка | Наверх | Cообщить модератору

252. "Релиз ядра Linux 3.18"  +/
Сообщение от pavlinux (ok), 10-Дек-14, 22:38 
> Если уж архитектурно, последовательный интерфейс от параллельного отличается аж

Идиот, ты хотя бы для начала провода на 80-жильном SCSI посчитал, и 7 у SATA


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

У тебя там случаем не карты Таро, очень смахивает на гадалку.

Ответить | Правка | Наверх | Cообщить модератору

255. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от mihalychemail (ok), 10-Дек-14, 23:02 
Мдааа. По ходу ты, Павлуня, окончательно деградировал в овощ.
Ответить | Правка | Наверх | Cообщить модератору

231. "Релиз ядра Linux 3.18"  +/
Сообщение от pavlinux (ok), 10-Дек-14, 01:02 
> /etc/sysctl.conf
> vm.overcommit_ratio = 80
> vm.overcommit_memory = 2
> vm.dirty_bytes = 8388608
> vm.dirty_background_bytes = 8388608
> vm.vfs_cache_pressure = 50
> помогает отлично.

К таким заявам хорошо бы прикладывать полный конфиг железа.
Мать, диски, SPD из RAMы, CPU,..., load average тоже и iostat c ним же.

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

241. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:19 
Размечтался то! Некоторые верят в серебряные пули. Ну или как ты - боятся последовательных интерфейсов. Или там чего еще. А ты эзернет не боишься? Или там HDMI, DP и прочих? А то там тоже последовательное пихание данных по дифференциальной паре, если что...
Ответить | Правка | Наверх | Cообщить модератору

256. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от settler001email (?), 10-Дек-14, 23:35 
>> помогает отлично.
> К таким заявам хорошо бы прикладывать полный конфиг железа.
> Мать, диски, SPD из RAMы, CPU,..., load average тоже и iostat c
> ним же.

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

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

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

>> vm.dirty_bytes = 8388608
>> vm.dirty_background_bytes = 8388608

Ответить | Правка | К родителю #231 | Наверх | Cообщить модератору

44. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:01 
И да, комп уже не первый, а проблема все та же.
Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

50. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 14:21 
> И да, комп уже не первый, а проблема все та же.

htop|top смотри, такого не бывает чтобы нельзя было увидеть что сжирает swap

Ответить | Правка | Наверх | Cообщить модератору

57. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 14:30 
>> И да, комп уже не первый, а проблема все та же.
> htop|top смотри, такого не бывает чтобы нельзя было увидеть что сжирает swap

Я невольно немного запутал описание. Даже если своп не задействован, а просто сохраняется состоояние 4Гб виртуалки с 8Гб физической озу на компе, то есть происходят интенсивные дисковые операции по записи на диск, все равно, например, в браузере кино замрет или почта повиснет. Если же в дело вступает своп (допустим две виртуалки работает), то все, каюк, у меня терпения часто не хватает дождаться. Но  хорошо то, что две виртуалки я зпускаю только что бы иногда глянуть изменилась ли ситуация с свопом. Как он не работал толком, так и не работает. Если бы что то текло я бы это вычислил сразу.

Ответить | Правка | Наверх | Cообщить модератору

257. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Классический аноним (?), 11-Дек-14, 07:35 
Мне кажется проблема наоборот с некоторыми программулинами, которые не любят в своп уходить. На компе с 4ГБ у меня постоянно дрались chromium и qemu. В qemu запущена ОСЬ с 512МБ, т.е. в итоге максимум 1ГБ должно есть. Хрому тоже 2ГБ по уши, но буквально 10 страниц и начинааааААААААется. Даже мышь не шевелится. Можно минут 10 подождать, в процессе чего у хрома будет прибит ООМом плагин Adblock и можно дальше работать.

Что самое смешное, поставил 8ГБ ОЗУ, та же конфигурация софта за пределы 4ГБ не вылазит и при этом уже всё ОК. Т.е. налицо некорректная работа когда РАМы мало. А не реальная нехватка оной.

Ответить | Правка | Наверх | Cообщить модератору

60. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:34 
> И да, комп уже не первый, а проблема все та же.

latencytop и sysdig вам в руки. Ну и просто понимание того как работает железо и как не гадить своей системе.

Ответить | Правка | К родителю #44 | Наверх | Cообщить модератору

59. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:33 
> на 3.16 стоит btrfs на руте и хомяк под ext4,

Типа, снапшоты самых ценных данных - роскошь? :)


Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

68. "Релиз ядра Linux 3.18"  +/
Сообщение от botman (ok), 08-Дек-14, 15:08 
Почему? Btrfs первый раз поставил, а ext4 у меня было... тупо копирую дерево с диска на диск не заморачиваясь
Ответить | Правка | Наверх | Cообщить модератору

145. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:12 
> Почему?

Потому что мысль снапшотить хомяка мне кажется весьма логичной. Хорошо помогает от лажи типа "rm -rf /home/somebody /some_dir/some_file". Мысль что хомяк не нуждается в такой защите мне не самоочевидна - пару раз я так очень обидно файлы портил, особенно невкусно было раскатать сравнительно старый бэкап при отсутствии более нового.

> дерево с диска на диск не заморачиваясь

Если допустить что btrfs надежно работает - логичнее было бы на самом деле оба диска в пул собрать и иногда делать снапшоты, а ценные данные так и вовсе можно разложить на зеркальный raid, например. При том это не зеркало на оба диска целиком, а только а объем ценных данных. А остальное можно без RAID. Или stripe для скорости. Я вот уже прицеливаюсь перевести на btrfs многодисковые конструкции, хоть это и потребует двигания данных. Зато есть надежда больше не налетать на такие операции в перспективе :)

Ответить | Правка | Наверх | Cообщить модератору

80. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от jemalloc (?), 08-Дек-14, 16:53 
ArchLinux x86_64. 16Гб. предыдушюю неделю была куча IO задач. Сделал так, что хотябы можно пользоваться. Поставил pf ядро. Выставил правильные io шедулеры. Вырубил свап, настроил page cache pressure. И вполне ничего, те гуи страницы которых были в памяти, нормально отрабатывали.
Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

146. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:13 
> которых были в памяти, нормально отрабатывали.

А если свопа нет и системный диск отдельным быстрым SSD сделать - так будет в 100% случаев.

Ответить | Правка | Наверх | Cообщить модератору

173. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:08 
Только предыдущее решение ничего не стоит, в отлииче от SSD
Ответить | Правка | Наверх | Cообщить модератору

208. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 17:11 
> Только предыдущее решение ничего не стоит, в отлииче от SSD

У вон того гражданина 16 гигз памяти. Своп ему даром не упал - ничего хорошего кроме дурных клинов системы по причине "доставали страницы с тормозного механического винча" своп ему не даст. А SSD - дает взлет системы со скоростью ракеты и такой же запуск программ. Очень мило когда какая-нибудь либра вываливается на экран за 1-2 секунды. Хорошая штука для растормаживания компьютера. Да, стоит денег. Но и работает здорово резвее и не зашивается там где механический диск дуба даст. Множественные параллельные чтения для SSD например пофигу, в отличие от.

Ответить | Правка | Наверх | Cообщить модератору

14. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 08-Дек-14, 10:17 
Как на убунту поставить?
Ответить | Правка | Наверх | Cообщить модератору

19. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 11:04 
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/
Ответить | Правка | Наверх | Cообщить модератору

27. "Релиз ядра Linux 3.18"  +/
Сообщение от paulus (ok), 08-Дек-14, 11:51 
cd ~/Загрузки && wget -c http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/li... http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/li... http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.18-vivid/li... sudo dpkg -i *.deb

и не забыть: sudo update-grub

Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

36. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 13:20 
не надо там груб апдейтить руками, сам проапдейтится в процессе установки ядра
Ответить | Правка | Наверх | Cообщить модератору

61. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 14:35 
> не надо там груб апдейтить руками, сам проапдейтится в процессе установки ядра

И ядро можно укачать lowlatency, раз уж такая пьянка. Разницы конечно мизер, но те кто вопит про клин на неудачной конфиге могут порадоваться, пожалуй.

Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 10:20 
aufs пора выпилить в свете OverlayFS
Ответить | Правка | Наверх | Cообщить модератору

23. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 11:24 
> aufs пора выпилить в свете OverlayFS

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

Ответить | Правка | Наверх | Cообщить модератору

130. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 03:46 
> aufs пора выпилить в свете OverlayFS

Про то, что aufs не в ядре, уже сказали.
От себя же хочу добавить про то, что overlayfs в текущем виде в подметки aufs-у не годится и годен, разве что для livecd. И тормознее, и всего 2 слоя поддерживает.

Ответить | Правка | К родителю #15 | Наверх | Cообщить модератору

174. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:11 
Насчет тормозов не знаю, но насчет слоев - "В качестве нижнего слоя, используемого только для чтения, могут применяться директории любых поддерживаемых в Linux систем, включая NFS и другие экземпляры OverlayFS"
Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 10:28 
Внимание, ядро с пока не устраненным багом (баг тянется с 3.17): http://lkml.org/lkml/2014/11/14/656
Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 11:09 
Судя по тексту - как раз в 3.17 всё было в порядке: "I'm not sure how long this goes back (3.17 was fine afair)"
Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 11:44 
читай ответы. там где-то Линус говорит, что код этой подсистемы не менялся с 3.17. А в анонсе к 3.18 есть такое:
>I'd love to say that we've figured out the problem that plagues 3.17 for a couple of people, but we haven't.

- как раз отсылка к этому самому багу, который упоминался и в анонсах к rc-версиям.

Ответить | Правка | Наверх | Cообщить модератору

32. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 12:37 
Ага, ясно. Не заметил
Ответить | Правка | Наверх | Cообщить модератору

94. "Релиз ядра Linux 3.18"  +/
Сообщение от Stax (ok), 08-Дек-14, 20:43 
Это есть такое :(
У меня на домашнем десктопе 3.17 не загружается вообще, равно как 3.18. Последнее нормально работающее - 3.16..
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

101. "Релиз ядра Linux 3.18"  +/
Сообщение от Карбофос (ok), 08-Дек-14, 21:51 
/var/log/messages в помощь. классика. в целом, проверяйте модули, однако
Ответить | Правка | Наверх | Cообщить модератору

148. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:17 
> У меня на домашнем десктопе 3.17 не загружается вообще, равно как 3.18.

Волобуев, где ваш баг? Или вы думаете что все должны угадать что у вас проблемы используя телепатию? Я вот гоняю RC и обычно успеваю вовремя пнуть причастных если что-то отвалилось. Поэтому у меня релизные ядра работают в высшей степени изумительно. На моем оборудовании. Чего и вам желаю :)

> Последнее нормально работающее - 3.16..

В конкретно 3.18 поначалу были какие-то race-подобные грабли. Потом гонкам дали бой и лично у меня проблемы ушли.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

17. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 10:30 
BPF - это по функциональности аналог netgraph, как я понимаю?
Ответить | Правка | Наверх | Cообщить модератору

112. "Релиз ядра Linux 3.18"  +/
Сообщение от DeadLoco (ok), 09-Дек-14, 00:16 
Нет, совершенно разные вещи.
Нетграф позволяет строить из нодов сложные конвейеры обработки пакетов, а бпф - только отфильтровывает из потока пакеты в соответствии с правилами на развитом языке.
Ответить | Правка | Наверх | Cообщить модератору

203. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 16:03 
>Нетграф позволяет строить из нодов сложные конвейеры обработки пакетов

а для чего строить эти конвейеры, как не для фильтрации пакетов из потока?

эх, ладно, может кто-то скажет более кратно и более конкретно, для чего netgraph используют, потому как BFP мне немного понятен. спасибо

Ответить | Правка | Наверх | Cообщить модератору

213. "Релиз ядра Linux 3.18"  +/
Сообщение от DeadLoco (ok), 09-Дек-14, 17:47 
> а для чего строить эти конвейеры, как не для фильтрации пакетов из потока?

Для обработки. Например, пакетам можно рихтовать src/dst для ната, можно менять им ТТЛ, можно шейпить, можно вести учет разный, можно выполнять разные преобразования.

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

Ответить | Правка | Наверх | Cообщить модератору

244. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:21 
> А фильтр только вычленяет из потока пакеты, которые удовлетворяют набору условий.

Что не мешает однако существовать ни нату, ни рихтовке TTL под линя. Может не так концептуально, но работает...

Ответить | Правка | Наверх | Cообщить модератору

33. "Релиз ядра Linux 3.18"  –3 +/
Сообщение от Аноним (-), 08-Дек-14, 13:02 
Хорошая новость! Так, ждём BFS, exfat-nofuse и vboxdrv, и обновляемся.
Ответить | Правка | Наверх | Cообщить модератору

34. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от afsdgdsfgf (?), 08-Дек-14, 13:11 
BFS не будет никогда, т.к. Коливас и начал пилить свой элеватор, т.к. разработчики Linux были с ним не согласны, а ExFat'а не будет из-за патентов, vboxdrv не будет, т.к. это блоб чистой воды, с таким-же успехом в ядро можно включать офф. блобы ATI и Nvidia.
Ответить | Правка | Наверх | Cообщить модератору

37. "Релиз ядра Linux 3.18"  +/
Сообщение от Zenitur (ok), 08-Дек-14, 13:43 
Да нет, ты не понял. Не в ядре, а обновление патчей. Вот например для 3.17: http://ck.kolivas.org/patches/bfs/3.0/3.17/
Ответить | Правка | Наверх | Cообщить модератору

38. "Релиз ядра Linux 3.18"  +/
Сообщение от Фанатик (?), 08-Дек-14, 13:44 
Так по этому и ждем пока обновят
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

150. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 08:18 
> таким-же успехом в ядро можно включать офф. блобы ATI и Nvidia.

Амдшники устали и теперь их блоб будет опенсорсным - amdgpu будет называться :)


Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

232. "Релиз ядра Linux 3.18"  +/
Сообщение от Led (ok), 10-Дек-14, 01:07 
> vboxdrv не будет, т.к. это блоб чистой воды

Идиот

Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

62. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Аноним (-), 08-Дек-14, 14:37 
> Так, ждём BFS,

Он имеет смысл разве что на 1-ядерной системе, да и там от него толк явно не окупает гемор с кастомным патчингом и ересборкой.

> exfat-nofuse

Нафига?

> и vboxdrv,

В линухе сто лет как есть KVM и вся эта возня по этому поводу означает лишь "я не умею пользоваться qemu".

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

88. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от AlexYeCu_not_logged (?), 08-Дек-14, 18:15 
Увы, kvm+qemu на сегодня заметно медленней vbox`а.
Ответить | Правка | Наверх | Cообщить модератору

147. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:13 
>Увы, kvm+qemu на сегодня заметно медленней vbox`а.

Вот я бы тут поспорил. У меня тоже есть оба, предлагаю обдумать как их тестировать.

Ответить | Правка | Наверх | Cообщить модератору

242. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 15:20 
>>Увы, kvm+qemu на сегодня заметно медленней vbox`а.
> Вот я бы тут поспорил. У меня тоже есть оба, предлагаю обдумать
> как их тестировать.

Триальный бенч: http://www.passmark.com/products/pt.htm
Особо интересны 2D graphics tests и 3D graphics tests.

Давай поржём над куему и вбоксом.

Ответить | Правка | Наверх | Cообщить модератору

154. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:25 
> Увы, kvm+qemu на сегодня заметно медленней vbox`а.

Не заметил. Я использую kvm для ряда околопродакшновых задач, типа проверки вещей потенциально способных сломать систему и мне скорость достаточно интересна. По памяти и cpu он близок к желзке. I/O конечно медленнее, спору нет. Но так у всех виртулизаторов. Что именно у вас тормозило?

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

243. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от pavlinux (ok), 10-Дек-14, 15:21 
> I/O конечно медленнее, спору нет. Но так у всех виртулизаторов.

Откройте для себя VMware ...

> околопродакшновых задач,

... жмоты!

Ответить | Правка | Наверх | Cообщить модератору

247. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 10-Дек-14, 15:34 
> Откройте для себя VMware ...

Да иди ты cо своей вмварью. У меня на виртуалках как правило не крутится интенсивных 2D/3D задач. Я больше бухтел про дисковый IO и сеть, и у вмвари с этим как-то более-менее обычно, насколько я свои эксперименты с ней помню. А так я в порядке извращения иногда пробрасываю GPU на виртуалку, qemu такие фортели тоже позволяет. Скорость при этом разумеется вполне железячная - PCI-E девайс он и есть PCI-E девайс, особо стормозить там вроде негде. Но это больше по приколу. Ну да, можно. Но юзкейс придумать достаточно сложно.  

> ... жмоты!

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

Ответить | Правка | Наверх | Cообщить модератору

254. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 22:52 
>[оверквотинг удален]
> и сеть, и у вмвари с этим как-то более-менее обычно, насколько
> я свои эксперименты с ней помню. А так я в порядке
> извращения иногда пробрасываю GPU на виртуалку, qemu такие фортели тоже позволяет.
> Скорость при этом разумеется вполне железячная - PCI-E девайс он и
> есть PCI-E девайс, особо стормозить там вроде негде. Но это больше
> по приколу. Ну да, можно. Но юзкейс придумать достаточно сложно.
>> ... жмоты!
> Не очень понимаю что мне твоя вмварь даст кроме геморроя с этим
> куском проприетари. Я виртуализаторы использую чтобы разгрузить себя от гемора а
> не добавить нового.

Ну понятно, если не умею - значит говно.

Ответить | Правка | Наверх | Cообщить модератору

91. "Релиз ядра Linux 3.18"  +/
Сообщение от llolik (ok), 08-Дек-14, 19:26 
>В линухе сто лет как есть KVM и вся эта возня по этому поводу означает лишь "я не умею пользоваться qemu".

Оно же вроде как аппаратной виртуализации требует. Не у всех она есть.

Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

95. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 20:50 
А где её нынче нет там, где вообще мощи хватит гонять виртуалку?
Ответить | Правка | Наверх | Cообщить модератору

108. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от llolik (ok), 08-Дек-14, 23:20 
> А где её нынче нет там, где вообще мощи хватит гонять виртуалку?

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

Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 02:47 
Стоп, насколько я помню, не умеют аппаратную виртуализацию разве что атомы?
Ответить | Правка | Наверх | Cообщить модератору

152. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от llolik (ok), 09-Дек-14, 08:31 
> Стоп, насколько я помню, не умеют аппаратную виртуализацию разве что атомы?

Поддерживают то да, только или софтварно в BIOS отключают(в Samsung такое было, причём и возможность включения убирали), или процессор идёт урезанный (типа Pentium B940 и тому подобное)
Впрочем, сейчас становится лучше, ибо, насколько я понимаю, винды выше седьмой/2008-ой уже без аппаратной виртуализации не заводятся в принципе. Так что хочешь не хочешь, а вкорячивают.

Ответить | Правка | Наверх | Cообщить модератору

164. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:50 
Чувак, называя вещи своими именами: если ты купил железку без аппаратной виртуализации, с хилым дисковым I/O и прочая - ты просто сказочно облажался в подборе конфиги под задачу и зачем-то пытаешься грубую лажу оправдать. От того что ты скажешь "халва" - во рту слаще не станет.

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

Ответить | Правка | Наверх | Cообщить модератору

176. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:15 
С идеей согласен, с примером - нет. Наличие виртуалок не обязательно предполагает серьезную нагрузку на них. Просто аппаратная виртуализация - это мейнстрим, и пытаться без неё обойтись - это уже "стоя в гамаке". А вот многодисковость - абсолютно необязательное требование. Лучше бы гору памяти упомянули, честно слово. да и ноутбук или десктоп - лично дело каждого, хотя как по мне - сейчас в 9 случаях из 10 рабочий ноутбук торчит там, где десктоп был бы гораздо уместнее - от эргономики до удобства апгрейда/ремонта.
Ответить | Правка | Наверх | Cообщить модератору

192. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 13:38 
> С идеей согласен, с примером - нет. Наличие виртуалок не обязательно предполагает
> серьезную нагрузку на них.

Тогда жалобы на производительность выглядят довольно странно. Вы не хотели учитывать worst cases и сэкономили? ОК, вы знали на что шли. Вот только устраивать самому себе оверселлинг который начинает икаться тормозами - это довольно странный и мазохистичный вариант. Если коммерческие оверселлеры дурят клиента, то вы дурите сами себя. А зачем?

> Просто аппаратная виртуализация - это мейнстрим, и
> пытаться без неё обойтись - это уже "стоя в гамаке".

Именно. Она есть в большинстве не сильно архаичных х86 железяк.

> А вот многодисковость - абсолютно необязательное требование.

А это к вопросу о том кого мы хотим обмануть на worst cases. Если себя - тогда не обязательно. А если хочется летать первым классом - тогда довольно странно экономить на самом себе. Вы уж или заботитесь об отсутствии тормозливости, даже при тяжелых нагрузках, или получаете лагучую систему, когда при тяжелом IO и душняке памяти оказывается что слоупочный диск (в ноуте 2.5" и чаще всего 5400 RPM всего) - надрывается на всю ораву и время выполнения запросов взлетело до небес, а куцый дисковый буфер даже не разгрузил его от дергания головами.

> честно слово. да и ноутбук или десктоп - лично дело каждого,

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

> рабочий ноутбук торчит там, где десктоп был бы гораздо уместнее -
> от эргономики до удобства апгрейда/ремонта.

Для начала - возможность впихнуть адекватно ресурсов и адекватно их распределить. Даже на самой поганой мамке есть несколько SATA разъемов и можно недорого набить кучу памяти. Да и проц в TDP не урезан. И виртуализацию ему никто не отключает.

Ответить | Правка | Наверх | Cообщить модератору

200. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:57 
Не надо лезть в экстремумы. Если раз в три года что-то понадобилось - часто проще скомпенсировать недостаточность железа разумным планированием, или просто потерпеть пол-часа тормоза. тем же первым классом мало кто летает - разве что деньги совсем девать некуда.

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

Ответить | Правка | Наверх | Cообщить модератору

209. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 17:25 
> потерпеть пол-часа тормоза.

А оно мне надо - терпеть тормоза?

> тем же первым классом мало кто летает - разве что деньги совсем девать некуда.

В данном случае - работа системы станет заметно приятнее глобально, и именно это - ответ нытикам насчет того что нечто клинит. И если первым классом летает не так уж много, то это не значит что ехать в душном переполненном плацкарте - хорошо и приятно. Я ж не предлагаю человеку купить за несколько килобаксов нормальный сервер с несколькими мощными процами, >=128 гиг памяти и кучей дисков, которые серьезные энтерпрайзники под виртуалки ставят, чтобы виртуалки там даже в виде "целая сеть" летали там первым классом. Я всего лишь предлагаю не устраивать бомжевоз.

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

Ну вот и я о чем.

> А вот второй диск - это уже затраты, которые надо бы как-то обосновывать,

Я вот себе обосновал: экономить на самом себе и своем удобстве и комфортной работе - самый гнилой способ экономии который можно придумать. А ждать компьютер - не больно приятная перспектива. ИМХО если уж девайс активно используется - пусть работает хорошо.

> И "хочу чтобы всё всегда летало" - с моей точки
> зрения никуда не годное обоснование.

А с моей - очень даже нормальное. Ждать тормозной компьютер - очень мерзкое и неприятное занятие. И контрпродуктивное. Я готов доплатить за избавление от такого "счастья" на машинах с которыми работаю часто и много. Потому что я себе не враг и поэтому оверселлить ресурсы самому себе нахожу крайне неумным занятием.

Ответить | Правка | Наверх | Cообщить модератору

193. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от llolik (ok), 09-Дек-14, 13:43 
Чувак, если бы через меня проходил только мой ноут, я бы и не говорил (к тому же покупал я его года три назад и совсем для других задач).
Я лишь хотел донести мысль о том, что людям кому не повезло с аппаратной виртуализацией, которых всё-таки чуть больше чем один я, тоже надо с чем-то работать. Только и всего.
Ответить | Правка | К родителю #164 | Наверх | Cообщить модератору

210. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 17:28 
> Я лишь хотел донести мысль о том, что людям кому не повезло
> с аппаратной виртуализацией, которых всё-таки чуть больше чем один я, тоже
> надо с чем-то работать. Только и всего.

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

Ответить | Правка | Наверх | Cообщить модератору

245. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от pavlinux (ok), 10-Дек-14, 15:25 
> Те кому надо работать с виртуализацией - заботятся о наличии аппаратной виртуализации на своем железе,

Ну у меня нет, аппаратной виртуализации. 2 x Opteron 285, 8 гиг ECC DDR1
Одновременно запущены Debian 7, два Debian 8 (x32 и х64), Вантуз 8, Вантуз ХП.

Ответить | Правка | Наверх | Cообщить модератору

248. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 10-Дек-14, 15:47 
> Ну у меня нет, аппаратной виртуализации. 2 x Opteron 285,

У этих еще не было? Вроде амд сто лет как ее запилил.

> 8 гиг ECC DDR1

16, DDR3, ECC. АМД позволяет нахаляву проскочить - на десктопной мамке. У как минимум FX-ов (у меня 8120, его выше крыши) контроллер памяти с ECC, на мамках это как правило разведено и BIOS тоже в курсе. Так что ECC unbuffered модули запускаются как из пушки, с ECC. Еще и IOMMU аппаратный - можно поизвращаться с пробросом PCI(-e) девайсов в виртуалки. Да и просто одуревшим девайсам дает по кумполу, just in case.

> Одновременно запущены Debian 7, два Debian 8 (x32 и х64), Вантуз 8, Вантуз ХП.

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

Ответить | Правка | Наверх | Cообщить модератору

163. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:46 
> На ноутбуках, например, не то чтобы часто встречается.

Странно, у меня на нотике которому 4 года - она уже есть.

> Мне вот периодически нужна даже сеть виртуалок. Память я конечно нарастил (16Гб
> вполне хватает), а вот проц и матплату в ноуте сменить, мягко
> говоря, если и возможно, то хлопотно.

А ноут под такие задачи вообще используют только те кто не в ладах со здравым смыслом. У ноутов слабое I/O. Уж как минимум 2 диска - милое дело. Один под систему и второй под данные и сильные нагрузки. А если виртуалок целая сеть - те кто в здравом уме вообще-то на несколько дисков это разносят. А утырки которые ожидают от ноутбука производительность сервера - получают то что получают, ибо чудес не бывает. Хотите хорошую производительность I/O - разносите по разным дискам. Механические диски, btw, многопоточный доступ не лю by design. А SSD это круто и быстро. Но малоемко и дорого. На нормальном десктопнике и тем более сервере это можно обыграть. А на ноуте - сложно...

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

177. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:20 
Ну у меня вот когда-то в виртуалке крутился foobar2000 с год. Как думаете, большая нагрузка ему была нужна? Или - стоит винда, в ней эксплорер - разрабатываемые странички в нйм сомтреть. Нужен там отдельный диск? Или - есть тулза для прошивки родного смартфона, работающая только под винду, как это долго было для MTK. Как полагаете, сильно это систему грузит? Или торчит отдельная виртуалка, на которой иногда заходят в клиент-банк. Бывает куча прикладных задач, для которых виртуалка не требует каких-либо мощностей.
Ответить | Правка | Наверх | Cообщить модератору

191. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 13:19 
> Ну у меня вот когда-то в виртуалке крутился foobar2000 с год. Как
> думаете, большая нагрузка ему была нужна?

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

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

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

> Бывает куча прикладных задач, для которых виртуалка не требует
> каких-либо мощностей.

При том нужда гонять оные на виртуалке чаще всего высосана из пальца. А тот же андроид шьется обычными утилсами из комплекта fastboot. Прям под линухом. И цепляется через adb из того же комплекта утилей.

Ответить | Правка | Наверх | Cообщить модератору

199. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:49 
меня под линуксом устраивает отвно один плеер - deadbeef. Когда его не было - фубар гонял. Но фишка в том, что потребляет оно одну десятую процента проца или пять - побоку абсолютно.

Как винда чудит - это контролируемо. Не нравится - отложил апдейт до момента, когда тебе комфортно.

Андроид на MTK не шьется фастбутом. Кроме того, flash tool много чего может - например, переразбить внутренний флеш для изменения размера разделов.

Вообще - о чем спор? Ты всерьёз готов утверждать, что не может быть ситуаций, когда вируталка нужна, но серьезной нагрузки на систему она не даёт?

Ответить | Правка | Наверх | Cообщить модератору

211. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 17:36 
> меня под линуксом устраивает отвно один плеер - deadbeef.

Честно говоря не очень понимаю чего у него уникального. Не, deadbeef неплохой плеер, но автор делом доказал что у него много невменяемых заскоков, напрочь несовместимых с моим видением управления софтом в системе.

> одну десятую процента проца или пять - побоку абсолютно.

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

> Как винда чудит - это контролируемо. Не нравится - отложил апдейт до
> момента, когда тебе комфортно.

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

> Андроид на MTK не шьется фастбутом.

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

> Кроме того, flash tool много чего может -
> например, переразбить внутренний флеш для изменения размера разделов.

Хорошая заявка на много долботни на ровном месте.

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

Для меня это выглядит как подгон решения под ответ. Такие ситуации бывают, НО обрубать себя только ими - это как-то не очень реалистично в целом.

Ответить | Правка | Наверх | Cообщить модератору

155. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:26 
> Оно же вроде как аппаратной виртуализации требует. Не у всех она есть.

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

Ответить | Правка | К родителю #91 | Наверх | Cообщить модератору

54. "Релиз ядра Linux 3.18"  +4 +/
Сообщение от zhenya_k (?), 08-Дек-14, 14:25 
>В DRM-драйвер Radeon для старых карт R600 добавлена поддержка UVD (Unified Video Decoder) для ускорения декодирования видео;

Так долго ждал, что видюха уже сдохла.

Ответить | Правка | Наверх | Cообщить модератору

89. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от ua9oasemail (ok), 08-Дек-14, 18:16 
В состав каких дистрибутивов вещь сия войдет? (А на каких них уже установленных может быть целесообразно поставить именно это ядро?) Насколько больше устройств в этом ядре поддерживается?
Ответить | Правка | Наверх | Cообщить модератору

98. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Пессимист (?), 08-Дек-14, 21:07 
Никаких. (Ни на какие). Нинасколько.
Ответить | Правка | Наверх | Cообщить модератору

156. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:28 
> (А на каких них уже установленных может быть целесообразно поставить именно это ядро?)

Я себе на хубунту 14.10 поставил. В основном для улучшения работы btrfs и ряда мелких плюшек по части амдшных GPU.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

92. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 19:31 
А rt kernel судя по всему совсем забросили.
Ответить | Правка | Наверх | Cообщить модератору

168. "Релиз ядра Linux 3.18"  +/
Сообщение от Andrey Mitrofanov (?), 09-Дек-14, 10:23 
> А rt kernel судя по всему совсем забросили.

Да, ты http://lwn.net/Articles/617140/ чо, правда!?

---С наступающим новым 2015ым годом!

Ответить | Правка | Наверх | Cообщить модератору

259. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 11-Дек-14, 18:38 
Как бы да http://lwn.net/Articles/572740/
И в рассылки у них пробегало в ноябре-декабре что практически всё заморожено.
Ответить | Правка | Наверх | Cообщить модератору

260. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Andrey Mitrofanov (?), 11-Дек-14, 20:42 
> Как бы да http://lwn.net/Articles/572740/
> И в рассылки у них пробегало в ноябре-декабре что практически всё заморожено.

Вот!! Так заканчивается бесплатная работа на дружественных корпорастов у тех, кто не перешёл на GPLv3+.

---Навеяло той ссылкой из новости про GCompris->KDE с соплями "ой, ужас, у него GPLv3"

Ответить | Правка | Наверх | Cообщить модератору

261. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 12-Дек-14, 17:46 
Надо читать то что было мааааленьким шрифтом написано:)
Ответить | Правка | Наверх | Cообщить модератору

93. "Релиз ядра Linux 3.18"  –4 +/
Сообщение от Аноним (-), 08-Дек-14, 20:36 
Вот как можно не включать(выключить) swap? Вы чем думаете вообще? Вы бы прежде освоили принципы страничной организации памяти в OS. Еще удивляется чего virtualbox у него "глохнет". Отключение swap нечего хорошего не принесет.
Ответить | Правка | Наверх | Cообщить модератору

96. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 08-Дек-14, 20:53 
Вообще-то польза от отключения свопа есть. Потому что некоторые программы - браузеры в особенности - судя по всему, своп от физической памяти отличать не хотят, зато отжирают себе в зависимости от общего объема. И потом не отдают. И система начинает свопиться даже тогда, когда полностью умещается в RAM. Отключаешь своп - и внезапно какой-нибудь файрфокс начинает тупить гораздо меньше.
Ответить | Правка | Наверх | Cообщить модератору

97. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 08-Дек-14, 20:59 
Программы и не должны отличать физическую память от свопа - ядро их тычет в виртуальное её представление. А уж как лучше всем этим добром распорядиться и что куда кидать, ему (ядру) и подавно виднее.
Ответить | Правка | Наверх | Cообщить модератору

122. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 02:52 
Ну вот в данном случае не прокатывает - без свопа тупит меньше. Похоже, оно что-то пытается "в памяти" держать, что дешевле пересоздать, чем сохранять на диск и потом тянуть обратно. Или, может, GC как-то по-другому начинает себя вести, уж не знаю.
Ответить | Правка | Наверх | Cообщить модератору

144. "Релиз ядра Linux 3.18"  +/
Сообщение от none7 (ok), 09-Дек-14, 07:40 
Единственное чем может помочь отключение swap, так это фактическим отключением кеша фс при дефиците памяти. Видимо в некоторых случаях ядро предпочитает данные программ сбросить на диск, а не кеш. Если бы системе стало реально не хватать памяти, то первыми бы слетел X-сервер, потому, что не умеют программы адекватно обрабатывать ситуацию malloc() == NULL.
Ответить | Правка | Наверх | Cообщить модератору

149. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 08:17 
Читал тред и вдруг пришла гениальная мысль: вместо firefox запустить firefox:i386 :)
Пойду и проверю насколько мысль гениальная..
Ответить | Правка | Наверх | Cообщить модератору

178. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:21 
У меня давало 30% разницы в потреблении памяти - но это было гда полтора назад. Буду благодарен, если отпишетесь о результате.
Ответить | Правка | Наверх | Cообщить модератору

179. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 12:22 
> Единственное чем может помочь отключение swap, так это фактическим отключением кеша фс
> при дефиците памяти.

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

Единственное что всякий dead code и такие же данные в своп могут выдавиться, но поскольку AI еще не изобрели, туда же может выдавиться и браузер или офисный пакет, который полдня никто не трогал. А когда они понадобятся - опаньки, ттооррммоозззааа.

> умеют программы адекватно обрабатывать ситуацию malloc() == NULL.

Для начала все это весьма иррелевантно управлению памятью в линуксе, где по дефолту оверкоммит врублен и oom killer возбухает. Так, FYI.

Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

180. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:24 
Во-первых, первым слетел бы тот, кого убил бы OOM. Во-вторых - со свапом траблы есть когда памяти достаточно. Не то, чтобы система колом вставала - но тормозит прилично, если запущено что-то развесистое вроде браузера с кучей страниц или IDE  с большим проектом. Моё предположение - что система не угадывает, что можно вытеснить в своп (а она его использует даже если памяти хвтает - освобождает её для файловых буферов, причем в основном - которые на чтение).
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

190. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 13:15 
> Во-первых, первым слетел бы тот, кого убил бы OOM.

Так весь пойнт в том чтобы поставить столько памяти, что OOM случается только при runaway и не случается при нормальной эксплуатации вообще совсем. Грубо говоря если у тебя 4 гига памяти и 4 гига свопа - с точки зрения приятности эксплуатации системы намного лучше будет поставить 8 гигз памяти и никакогош свопа. При этом будут доступны те же 8 гигз, только последние 4 гига не будут добиваться с истошным тормозиловом и клином всего что угораздило выпасть в своп. Мало 8? Ок, поставим 16. Все-равно ты с практической точки зрения опупеешь от времени (пере)записи и чтения свопа крупнее 1-2 гигов. Я как-то совсем не готов десятками минут ждать пока система протормозится.

> с кучей страниц или IDE  с большим проектом. Моё предположение
> - что система не угадывает, что можно вытеснить в своп

Искусственный интеллект, который заранее знает что приспичит пользователю - еще не изобрели. Поэтому естественно в своп будет улетать как dead code и такие же данные, так и то что потом через полдня юзеру понадобится (но система про это ессно не знала).

> файловых буферов, причем в основном - которые на чтение).

Как по мне - так идея выиграть дисковый буфер для ускорения I/O за счет тормозов от свопления - очень спорная идея, мягко говоря.

Ответить | Правка | Наверх | Cообщить модератору

197. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:26 
Лично мой пойнт в том, чтобы не покупать то, что даёт копеечные приросты. Если у тебя четыре гига, а ещё четыре используются раз в месяц для пересборки, которую можно вообще на ночь зашедулить - глупо их покупать. При этом при наличии постоянно включенного свопа - да, в него (за отсутстсвием искусственного интеллекта и libastral) улетает то, что иногда нужно пользователю. И ни разу не через пол-дня, речь о минутах в случае браузера.

Логичный вывод - обычно живём без свопа, когда он нужен - временно его включаем.

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

Ответить | Правка | Наверх | Cообщить модератору

212. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 17:47 
> Лично мой пойнт в том, чтобы не покупать то, что даёт копеечные приросты.

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

Я говорю как сделать чтобы не тормозило. А вы говорите что "и так сойдет!". Хотя изначальная постановка вопроса подразумевает что вопрошавшему так не нравится и видимо все-таки не сойдет.

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

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

По вашей логике кровати покупают только глупцы. Ведь можно же поспать и на полу. Тем более что вы это делаете только 8 часов из 24, не так уж и много вроде.

> о минутах в случае браузера.

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

> Логичный вывод - обычно живём без свопа, когда он нужен - временно
> его включаем.

Тоже вариант, но мне своп элементарно не требовался на основной машине уже лет пять. Все задачи влезают в тамошний объем RAM и если там OOM случился - это значит что нечто пошло вразнос.

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

Я предпочитаю ситуацию когда свопа нет совсем а дисковые буфера большие. При этом с системой элементарно приятно работать - ее никогда не клинит. Ну это примерно как пересесть из вонявшего бензином в салоне и гремящего жигуленка в комфортную иномарку с кондеем.

Ответить | Правка | Наверх | Cообщить модератору

157. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:31 
> тупить гораздо меньше.

Ну еще бы. Одно дело страницы медленно и печально с механического диска доставать и совсем иное если они готовенькие, в физической памяти лежат. К вопросу о том чего мы там не понимаем по части страничной памяти.

p.s. и да, линух умеет оверкоммит - сколько там виртуальной памяти попросят программы не принципиально. Пока они ее не поюзали по факту - она вообще ядром не выделяется. Чисто циферка в top.

Ответить | Правка | К родителю #96 | Наверх | Cообщить модератору

100. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 21:32 
А что еще делать, если использование этого самого свопа вешает систему наглухо? Смысл тогда его вообще включать, так глядишь oom прибъет что и пропердится, а со свопом чаще только ребут.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

113. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Mihail Zenkov (ok), 09-Дек-14, 00:21 
Сам давно отказался от свопа. Но есть и правда в том, что ядро может вести себя неадекватно при его отключении:
https://bbs.archlinux.org/viewtopic.php?id=144702

Сам иногда наблюдаю такую же картину. Ядро собрано без поддержки свопа, но процесс kswapd0 есть. Это конечно баг, а не "так и было задумано".

Ответить | Правка | Наверх | Cообщить модератору

158. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:33 
> Сам иногда наблюдаю такую же картину. Ядро собрано без поддержки свопа, но
> процесс kswapd0 есть. Это конечно баг, а не "так и было задумано".

А у меня ядро хоть и с поддержкой свопа, но ни 1 свопа не подцеплено. И никаких проблем, соотвественно.

Ответить | Правка | Наверх | Cообщить модератору

131. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 03:51 
> Вот как можно не включать(выключить) swap? Вы чем думаете вообще? Вы бы
> прежде освоили принципы страничной организации памяти в OS. Еще удивляется чего
> virtualbox у него "глохнет". Отключение swap нечего хорошего не принесет.

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

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

160. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:40 
> прежде освоили принципы страничной организации памяти в OS.

Мы освоили. И поняли что при текущих ценах на память довольно глупо заниматься вытаскиванием страниц из свопа если можно их в физической памяти разложить. Нафиг надо тормозную эмуляцию памяти из слоупочного харда, когда можно настоящую быструю память поставить? Оперативка работает со скоростью порядка пары десятков гиг в секунду и временем доступа которым можно принебречь в большинстве случаев. Хард читает ну самый край 200 мегов в секунду, а seek time может быть десятки миллисекунд. Так что эмуляция памяти получается крайне тормозной.

Это имело смысл на машинах где юзер еле-еле втыкал 8 мегов памяти и кой-как добивал недостающее свопом, потому что больше или не лезло технически, или делало в кошельке дыру. Но сайчас все это неактуально.

Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

181. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:29 
Чепуха, очередное обобщение. Допустим, я иногда собираю хром или файрфокс. Они в пике выжирают несколько гиг памяти. Вот для этого врубить временно своп гига на три-четыре - хорошо, позволяет параллельно серфить (да, с некоторыми тормозами) или читать или видео сомтреть (а вот здесь тормоза не прибавляются) или что там еще делаешь.

Нет универсальных решений, ну включайте вы голову, черт возьми.

Ответить | Правка | Наверх | Cообщить модератору

185. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 09-Дек-14, 12:38 
> Нет универсальных решений, ну включайте вы голову, черт возьми.

Добивать быструю оперативу мелденным винчом - это по современному состоянию дел просто эталонный идиoтизм. Универсальное решение - воткнуть 8 гиг или более. А выюзать 16 нетривиально даже открыв в хромиуме кучу дряни и запустив пару виртуалок, попутно компиля что-то жирное. Проверено. Еще и дисковому кешу остается. А в современные мамки можно и 32 набить. Мне просто как-то 16 хватает выше крыши, поэтому заняты только 2 слота из 4...

А своп - источник тормозов. Если на HDD. Или помощь в быстром залете на бабки. Если на SSD. Совет вкатить максимум оперативки который некто может позволить себе и вырубить своп - вполне универсальный, как минимум для серверов, десктопов и ноутов. Ну да, в каком-нибудь домашнем роутере память добавить сложно. Но там и свопиться чаще всего некуда. Тем паче что отвал свопфайла может уронить всю систему.

Ответить | Правка | Наверх | Cообщить модератору

196. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:14 
Универсальное решение - это собирать систему под имеющиеся задачи, а не под то, что делается раз в три жизни. Это во-первых. А во-вторых - сборка - это фоновый процесс, и плевать (в разумных пределах) сколько она займёт, лишь бы остальной деятельности, происходящей в это время (а не любой, какая приснится) не мешала.

И, что характерно, в отличие от покупки SSD или оперативки, включение мозга - оно бесплатное.

Ответить | Правка | Наверх | Cообщить модератору

214. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:00 
> Универсальное решение - это собирать систему под имеющиеся задачи, а не под
> то, что делается раз в три жизни.

Разумное решение - если это нечто типа системы продвинутого пользователя или разработчика, да еще основной рабочий инструмент - взять с запасом, чтобы покрыть именно worst cases.

Понимаешь, если ты купил дрель которая никак не может сверлить дыры более 5 миллиметров, а тут приспичило просверлить дыру в 10 миллиметров - будет глупо хвататься за голову и бежать за новым инструментом или хардкорно долбаться с маломощным, явно не тянущим задачу. Разумнее брать инструмент с некоторым запасом на worst case. Чтобы в этот случай "раз в месяц" не чесать репу "блин, и что мне теперь делать?".

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

При наличии свопа будет мешать - просто потому что в своп попадут не только сборочные процессы но и остальные, что вызовет деградацию времен отклика и проседание производительности системы в целом. Потому что гонять 50 миллисекунд головы чтобы получить плевок в 4 кило, который будет выполнен условно-мгновенно и понадобится еще плевок в 4 кило - это крайне контрпродуктивная активность системы. У буржуев это называется термином "computer is thrashing".

> И, что характерно, в отличие от покупки SSD или оперативки, включение мозга
> - оно бесплатное.

А ожидание системы - оплачивается своим временем и неприятными ощущениями.

Ответить | Правка | Наверх | Cообщить модератору

194. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 13:50 
И нафуа мне эта хрень из прошлого века, при 64Гб памяти? Вообще, эмулировать оперативку разделом на жестком диске - нездоровая идея, оправданная в те времена, когда память была маленькая и дорогая, а сейчас в этом и вовсе никакого смысла нет.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

99. "Релиз ядра Linux 3.18"  –3 +/
Сообщение от Аноним (-), 08-Дек-14, 21:18 
Именно. Отключая swap вы нарушаете нормальную, а главное эффективную работу менеджера памяти. Подкрути vm.swappiness если нужно, но ни в коем случае не отключать! Swap придумали не просто так. Он просто необходим для нормальной работы OS.
Ответить | Правка | Наверх | Cообщить модератору

102. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от бедный буратино (ok), 08-Дек-14, 21:53 
веееендузяяяяяяяяяяяяяяяяяяятник

ps. своп не использую с тех пор, как на компьютере впервые появилось 512 мб памяти, в не помню каком году. ни в linux, ни в openbsd, ни в системах, которые загружаются вообще без носителей. вы вообще в курсе, что это не винда, и она не обязана загружаться с диска цэ, а может загружаться с сети? и диска может не быть вообще? и что это ШТАТНЫЙ режим работы

Ответить | Правка | Наверх | Cообщить модератору

107. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Resonance (ok), 08-Дек-14, 23:11 
8 гб ОЗУ, swap не использую уже года 3, ни разу проблем не было.
Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

161. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 09-Дек-14, 09:41 
> 8 гб ОЗУ, swap не использую уже года 3, ни разу проблем не было.

Уже пять лет использую машины с 8, а потом и 16 гигз и вообще забыл что такое ситуация в которой компьютер тормозит. Да, а еще у меня KVMные виртуалки есть.

Ответить | Правка | Наверх | Cообщить модератору

126. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от odd.mean (ok), 09-Дек-14, 03:06 
Если острая нехватка ОЗУ - есть zram. Но никак не дисковый своп (особенно, на серверах).
Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

162. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 09:42 
> (особенно, на серверах).

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

Ответить | Правка | Наверх | Cообщить модератору

165. "Релиз ядра Linux 3.18"  +/
Сообщение от odd.mean (ok), 09-Дек-14, 09:53 
>> (особенно, на серверах).
> На десктопе тоже надо себя очень сильно не любить, чтобы при текущих
> ценах на память добивать нехватку памяти не реальной оперативой а тормозливой
> эмуляцией за счет диска.

Согласен полностью. Даже на стареньком недобуке с 1ГБ ОЗУ и zram на 2/3 объёма ОЗУ уже года 2 нет дискового свопа (даже для страховки от OOM-Killer). Debian testing + MATE + кастомное ядро с pf-patch (с UKSM). Огнелис бегает, мультимедиа бегает, торренты качают. Что вообще за мифология с этой подкачкой на диск? Если всё на винт полетит - никакой стабильности это системе не добавит. Тут уж лучше - если памяти мало - "бери ношу по себе, чтоб не падать при ходьбе".

Ответить | Правка | Наверх | Cообщить модератору

182. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 12:30 
Ну вот мне тоже как-то не втыкает при каком-нибудь runaway процессе ждать 10 минут пока своп забьется, чтобы потом наконец oom killer пришиб виновника. Лучше пусть через несколько секунд прибьется.
Ответить | Правка | Наверх | Cообщить модератору

183. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:31 
Просто задачи у вас не те, где от свопа есть выигрыш. Допустим, сборка большой библиотеки, которая может выжрать несколько гиг оперативки, со свопом работает довольно спокойно, не особо тормозясь (а если и есть тормоза - это процесс не интерактивный, плевать).
Ответить | Правка | К родителю #165 | Наверх | Cообщить модератору

186. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от odd.mean (ok), 09-Дек-14, 12:43 
Ну не на ideapad S100 же такие либы компилять! Для этого есть десктоп и свой сервачок. Да и ничего крупнее самого ядра лично для себя давно уже не собирал. Ядро и на нетбуке собиралось раньше нормально (перестал на нём собирать).

P.S.: ZRAM использую везде где применимо: кроме сервака (и так хватает) и одного VPS (там гвоздями всё прибито). Сначала опасался на боевых юзать, но при осторожном vm.swappiness (не менее 80), всё стабильно. Ну или просто я везучий.

Ответить | Правка | Наверх | Cообщить модератору

188. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 12:54 
> Ну не на ideapad S100 же такие либы компилять!

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

Ответить | Правка | Наверх | Cообщить модератору

201. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 15:04 
Да какой ideapad. Десктоп. 3 ядра, 4 гига памяти. И хватает. Дисков, правда, штабель, и не самых плохих (как-то пристарстился к серверным хитачам - во оснвоном из-за срока гарантии) - но по факту используется активно один, да на втором торренты живут. zram нет, есть zswap. Гента, так что пересборки иногда бывают весьма объёмные. При этом всём со свопом компиляция почти не заметна (благо, её всегда можно придушить и загнать в фон, что давно где-то в скриптах сделано), в отличие от тупизны браузера с горой джаваскриптов, с чем пришлось бороться радикально - noscript сотоварищи.
Ответить | Правка | К родителю #186 | Наверх | Cообщить модератору

215. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:07 
> Десктоп. 3 ядра, 4 гига памяти. И хватает.

Оно и видно - все пальцы отбил о клавиатуру, доказывая оптимальность такого выбора.

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

Кстати у меня самому старшему из хитачей 6.5 лет уже. И работает себе, SMART идеальный, никаких признаков скорой кончины не подает.

> Гента, так что пересборки иногда бывают весьма объёмные.

Те кто не хочет делать это стоя, в гамаке - берут нечто с 6-8 ядер, кучей оперативы и прочая. Ибо билдферма и есть билдферма. И конфиг надо выбирать билдфермовский. Хотя некоторые конечно любят доказательства вида "а мой виндовс не глю...unhandled error". Вот у вас так же на вашей конфиге линукс совсем не тттооррмммооозззиииитттт.

> радикально - noscript сотоварищи.

А это давно пора. Ибо иначе пачка скриптов может начать изрядно грузить проц. Не то чтобы он у меня в полку грузится, но раскрутка вентилятора на ровном месте как под интенсивные вычислительные задачи - не рулит.

Ответить | Правка | Наверх | Cообщить модератору

187. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 12:47 
> сборка большой библиотеки, которая может выжрать несколько гиг оперативки,

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

> со свопом работает довольно спокойно, не особо тормозясь

Как я уже сказал, в моем стиле - пустить билдовку ядра в 8 потоков и пойти рубануться раунд в xonotic. А минути через 15-20 можно пойти и забрать готовое ядро.

Заметь, 8 потоков компиляции и оптовый I/O не мешают мне метко навешивать окружающим headshot'ы из nex-а. А все потому что памяти глобально хватает, свопа нет, I/O системы и процесса сборки разнесен по разным накопителям (а под систему еще и SSD, по тем же причинам). Такой системе просто негде встать колом на уровне ее физического устройства,  у нее отличное время отклика. Всегда. Перманентно. Это компьютер который не тормозит - там на уровне железа сложно нагнуть I/O до состояния когда это начнет отражаться на пользователе и интерфейсе с оным. Я могу спокойно смотреть видео и никакие кадры выпадать не будут. Потому что браузер и его кэш даже и не пытались конкурировать с процессом сборки за бандвиз диска. А толстый дисковый буфер в который все улетело к тому же позволил оптимизировать полеты голов накопителя, а не истерично дергать винч, т.к. кэш уже больше класть некуда.

> (а если и есть тормоза - это процесс не интерактивный, плевать).

Если это ящик который пашет где-то в фоне - да, плевать. А если за монитором сижу я и на все это смотрю - мне как-то не плевать на времена отклика, вот извините...

Ответить | Правка | К родителю #183 | Наверх | Cообщить модератору

195. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 14:01 
Теории это хорошо, только я о собственном опыте рассказываю. Ядер у меня три, так что потоков компиляции, соответственно, четыре. Что ххарактерно - именно минут 15-20 ядро и занимает при этом. Как оно там разбирается - не знаю, но очень подозреваю, что поведение ядра именно под подобными нагрузками и тюнинговалось.

Ну и да, я сторонник здравого смысла и хороших соотношений "цена/результат", а не "идеал любой ценой". Если в эти двадцать минут я не буду гонять реалтаймовую игрушку - это, по-моему, вполне нормально. А более стационарный гуй, вроде того же браузера, ведёт себя прилично.

Ответить | Правка | Наверх | Cообщить модератору

216. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:19 
> Теории это хорошо, только я о собственном опыте рассказываю.

Так это не теория. Это то как я собираю себе компьютеры. Котрые не тормозят. Вообще никак и никогда. Что и хотели спрашивавшие, судя по всему.

> Ядер у меня три, так что потоков компиляции, соответственно, четыре.

... а остальные задачи изрядно просядут. ИМХО если компом планируется активно пользоваться, то логично ставить -j по числу ядер или даже n-1, если скорость пофиг.

Кроме того у моего проца хоть и 8 ядер но по блокам выполнения оно реально несколько ниже и 8 потоков - как раз более-менее полностью прогружают и целочисленые блоки и блоки плавучки. Ядра в современных процессорах тоже достаточно виртуальная сущность.

> Что ххарактерно - именно минут 15-20 ядро и занимает при этом.

У меня 15 минут занимает пересборка с референсным конфигом от убунты. А там весьма много драйверов. А вы поди как истинный гентушник перекомпиливаете ядро воткнув новый девайс? :)

> подобными нагрузками и тюнинговалось.

Хз, линковка модулей жестоко насилует диск. Но поскольку это не системный диск - всем пофигу :). А большой дисковый буфер к тому же делает большинство операций с скоростью больше характерной для SSD.

> Ну и да, я сторонник здравого смысла и хороших соотношений "цена/результат",

Я тоже. И чтобы не купить себе 8-16 гигз памяти в десктоп в 2014 году - надо быть буквально бомжом.

> а не "идеал любой ценой".

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

> Если в эти двадцать минут я не буду гонять реалтаймовую игрушку - это,
> по-моему, вполне нормально.

А по-моему, не вполне нормально если машина и ее особенности будут диктовать мне чем заниматься. Не вполне нормально ждать реакции машины. И не вполне нормально натыкаться на тормоза. Мне все это не нравится и я сделал так чтобы этого не видеть. Вообще совсем - на уровне физического устройства машины.

> А более стационарный гуй, вроде того же браузера, ведёт себя прилично.

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

Ответить | Правка | Наверх | Cообщить модератору

159. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 09:36 
> Swap придумали не просто так. Он просто необходим для нормальной работы OS.

Булшит. При современных ценах на память нет никакой нужды эмулировать память тормозным патефоном с магнитными головами. С точки зрения эффективности быстрее всего просто пойти и обратиться к странице в физической памяти. Без канители по ее выколупыванию с тормозного патефона. Это - эффективнее всего.

//обладатель реально быстрой системы которую не клинит вообще. Даже когда я ядро в 8 ядер компиляю и линкую, попутно рубаясь в xonotic.

Ответить | Правка | К родителю #99 | Наверх | Cообщить модератору

104. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 08-Дек-14, 22:40 
А ты запусти какой-нибудь Eclipse... И не надо начинать басни о Java. Есть система и в ней должно работать все что я пожелаю на ней запустить. Или игру ААА класса на худой конец. Подогнать систему под конкретный usecase для десктопа - не вариант. Предлагаю все же обратиться к соответствующей литературе.
Ответить | Правка | Наверх | Cообщить модератору

105. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 08-Дек-14, 22:51 
Расскажи это моим 16гигам озу
Ответить | Правка | Наверх | Cообщить модератору

117. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 01:14 
Расскажите это тем у кого "а-а-а!!! Файерфокс опять сожрал всю мою оперативу!!!1111".
Ответить | Правка | Наверх | Cообщить модератору

118. "Релиз ядра Linux 3.18"  +/
Сообщение от EHLO (?), 09-Дек-14, 01:19 
> Расскажите это тем у кого "а-а-а!!! Файерфокс опять сожрал всю мою оперативу!!!1111".

Расскажи чем поможет своп в такой ситуации.

Ответить | Правка | Наверх | Cообщить модератору

151. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 08:22 
>Расскажи чем поможет своп в такой ситуации.

очень просто: от дискового I/O из-за своппинга юзвери не смогут писать свою чушь вроде "а-а-а!!! Файерфокс опять сожрал всю мою оперативу!!!1111"

Ответить | Правка | Наверх | Cообщить модератору

218. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 18:22 
> чушь вроде "а-а-а!!! Файерфокс опять сожрал всю мою оперативу!!!1111"

Пожалуй можно засчитать за фичу вместо бага - мы отдохнем от их глупых коментов :).

Ответить | Правка | Наверх | Cообщить модератору

123. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 02:57 
Как раз подкрутить систему (включая себя) под свой юз-кейс - это правильный путь. От покупки нужного железа до настроек софта и до приучения себя решать задачи оптимальным способом, а не как левой пятке захотелось.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

219. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:24 
> Как раз подкрутить систему (включая себя) под свой юз-кейс - это правильный путь.

Не, вот извините. Подкручиваться под железки самому мне как-то не хочется. Я лучше железки буду выбирать так чтобы мне подкручиваться не приходилось. Пусть железки подкручиваются. Им пофиг, они железные. В отличие от меня, который может и задолбаться подкручиваться, ждать, ограничивать себя в юзкейсах лишний раз и прочее.

Ответить | Правка | Наверх | Cообщить модератору

109. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 00:11 
С большим объемом работа со swap протекает еще эффективней. Система сбросит часть неиспользуемых страниц в файл подкачки. Алгоритм не сбросит в файл-подкачки релевантные страницы. Такое поведение характерно только в случае острой нехватки физической памяти. Возникает эффект постоянного перемещения страниц памяти на диск и обратно. Программы продолжат работать в нормальном режиме. Нет необходимости в отключении подкачки. Никакого вреда как с маленьким объемом памяти так и с большим. Все это происходит из за непонимания или нежелания разобраться в механизме работы системы подкачки.
Ответить | Правка | Наверх | Cообщить модератору

115. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Mihail Zenkov (ok), 09-Дек-14, 00:39 
В теории все гладко, на практике:
1. Если память выделена, то она рано или поздно используется, иначе это баг программы. Соответственно, если памяти хватает - то мы лишь затормаживаем систему.
2. Если памяти не хватило, то работу нельзя назвать комфортной и своп не спасет,
3. Если своп на ноуте hdd, а ноут на АКБ - то есть вероятность, что периодически придется ждать пока раскрутится винт. Также это плохо скажется на времени автономной работы.
4. Как уже отметили - программы могут не экономично расходовать память, так как думают что памяти много и выделяют больше под кеш и реже проводят сборку мусора.
Ответить | Правка | Наверх | Cообщить модератору

225. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 19:00 
Ну как-бы что-то подсказывает, работа от АКБ и запуск большого количества приложений или тяжёлых приложений - не вариант.
Ответить | Правка | Наверх | Cообщить модератору

125. "Релиз ядра Linux 3.18"  +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 03:04 
1) ошибочно закладываясь на большую память программа держит "в памяти" (и периодически использует) кэши, без которых отлично может обойтись.

2) нечасто используемая программа выпихивается в своп ради дисковых буферов, что даёт какй-то прирост быстродействия, но не особо заметно на десктопе. Зато тормоза, когда раз в час обращаешься к софтине, а система её со скрипом тащит с диска - заметны отлично.

3) система плохо угадывает, что когда понадобится программе - что сплошь и рядом происходит с неактивными кладками браузера. Их вытесняет (опять-таки ради буферов, как правило), а потом прилетает таймер в JS или событие сети и их тащит обратно.

Наверняка и другие примеры найдутся.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

220. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:28 
> страниц в файл подкачки. Алгоритм не сбросит в файл-подкачки релевантные страницы.

Кроме того момента что какая-нибудь фигня в браузере, которую полдня не трогали - тоже уйдет в своп как "нерелевантная". Ведь никто же этим не пользуется. А то что мне через полдня туда приспичит переключиться - система наперед не знает.

> это происходит из за непонимания или нежелания разобраться в механизме работы
> системы подкачки.

Элементарная логика подсказывает мне: самый быстрый способ работы со страницами памяти - это когда они немедленно доступн в физической оперативке. Попробуйте оспорить.

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

111. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 09-Дек-14, 00:15 
Кратко: нет объективных причин отключать механизм подкачки. Нанести вред - вполне.
Ответить | Правка | Наверх | Cообщить модератору

114. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 00:29 
Кратко: веееендузяяяяяяяяяяяяяяяяяяятник
Ответить | Правка | Наверх | Cообщить модератору

153. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Аноним (-), 09-Дек-14, 08:31 
>Кратко: нет объективных причин отключать механизм подкачки. Нанести вред - вполне.

У меня 32 гб - вот объективная причина не иметь своп. Я буду только рад если OOM-killer убъет кривую софтину в ту же секунду как она съест всю доступную память. Ну а я поспешу удалить эту кривую поделку из системы.

Мы в университете на компьютерах с ОЗУ 256 Мб легко производили вычисления где только объем исходных данных был под 10 Гб.

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

263. "Релиз ядра Linux 3.18"  +/
Сообщение от KinderSurprise (?), 17-Дек-14, 23:36 
> У меня 32 гб - вот объективная причина не иметь своп. Я
> буду только рад если OOM-killer убъет кривую софтину в ту же
> секунду как она съест всю доступную память. Ну а я поспешу
> удалить эту кривую поделку из системы.

Вы сильно себе льстите :-)
Начиная с того, что даже не задумывались, что память съедят все "софтины". Не одна какая-то...
И кончая радостным пользованием кривыми софтинами...

Ответить | Правка | Наверх | Cообщить модератору

221. "Релиз ядра Linux 3.18"  –2 +/
Сообщение от Аноним (-), 09-Дек-14, 18:29 
> Кратко: нет объективных причин отключать механизм подкачки. Нанести вред - вполне.

Булшит. На системе с большим объемом памяти это избавит от шансов нарваться на тормоза и улучшит отзывчивость системы. А ситуация нехватки памяти - это что такое в системе с большим объемом памяти?

Ответить | Правка | К родителю #111 | Наверх | Cообщить модератору

119. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 02:09 
Михаил. Если памяти хватает, то необходимые страницы памяти никогда не попадут в подкачку. Туда попадут только те страницы которые долгое время не использовались! В итоге мы получаем более эффективное использование памяти: необходимые страницы всегда в памяти, а страницы реальной необходимости в которых нет - на диске. Никакого замедления! Ядро знает что, как и куда поместить! Сомневаюсь, что вы лучше разбираетесь в этом вопросе чем текущие разработчики ядра! Что до ноутбука. Вам стоит правильно настроить политику электропитания вашего HDD. Частые циклы включения-выключения плохо скажутся на его "здоровье"! Судя по тому, что вы высказали данный довод против файла подкачки, предположу слабую активность дисковой подсистемы и слабую общую нагрузку. Все это решается правильно настройкой vm.swappiness. Нет нужды отключать механизм!
Ответить | Правка | Наверх | Cообщить модератору

124. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Mihail Zenkov (ok), 09-Дек-14, 03:01 
> Михаил. Если памяти хватает, то необходимые страницы памяти никогда не попадут в
> подкачку.

Так чего бы их сразу тогда в /dev/null не отправить? :)

Ответить | Правка | Наверх | Cообщить модератору

184. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Crazy Alex (ok), 09-Дек-14, 12:33 
Угу, в богатой фантазии. А в реальности система иногда не угадывает, в каких страницах необходиомость есть - например, они используются раз пару минут - когда вы переключаете вкладку в бранузере и, соответственно, каждый раз нарываетесь на подтормаживание
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

222. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 09-Дек-14, 18:32 
Теоретически может получиться чуть больше RAM за счет слива dead code и данных в своп. Но при объеме в ..цать гигов это очень незначительный выигрыш. А вот проигрыш от ожидания пока вон та куча "якобы ненyжных" страниц достанется из свопа - может быть достаточно ощутимым. И на мое нескромное мнение когда в системе 8 гигз и более - от свопа по этому поводу больше вреда чем пользы. Свопом можно добить несколько мегов. Но несколько гигов на механическом носителе - это просто уcpaться как тормозно.
Ответить | Правка | Наверх | Cообщить модератору

235. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 08:13 
Противники свопа не пользуются спящим режимом на ноутбуках, да.
Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

249. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:54 
> Противники свопа не пользуются спящим режимом на ноутбуках, да.

Я не пользуюсь - suspend to ram намного быстрее, 1-2 секунды. Ждать пока тормозной патефон запишет или прочитает кучу данных мне лениво. А STR - буквально за секунду-другую в спячку выпадает. И аналогично из нее вываливается.

Ответить | Правка | Наверх | Cообщить модератору

175. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Zenitur (ok), 09-Дек-14, 12:14 
Насчёт SWAP. Когда там сделали CFS? 2.6.23? Мне кажется, это он поломал SWAP, в том плане что раньше система не вставала колом при малейшей попытке его использовать. Я помню как пробовал Linux первый раз в 2006 году, и отметил очень хорошую работу со SWAP: да, Amarok стартовал минуту, но геймплей в Wine (который и сожрал память) при этом не нарушился.
Ответить | Правка | Наверх | Cообщить модератору

202. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Gannetemail (ok), 09-Дек-14, 15:59 
>В DRM-драйвер Radeon для старых карт R600 добавлена поддержка UVD (Unified Video Decoder) для ускорения декодирования видео;

Добавить - добавили. А вот работать на таких, например, как HD2xxx - болт на три: валит всю систему в осадок.

Ответить | Правка | Наверх | Cообщить модератору

223. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 18:34 
> болт на три: валит всю систему в осадок.

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

Ответить | Правка | Наверх | Cообщить модератору

226. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Gannetemail (ok), 09-Дек-14, 19:57 
>> болт на три: валит всю систему в осадок.
> Так пиши баги. Фиче без году неделя. И если ты думаешь что
> все разработчики с энтузиазмом занимаются такой археологией... ну.... как бы тебе
> сказать, чтобы не очень расстроить?

Ой, только не думай, что ты самый умный, Аноним(ст). Баг-репорт написан ещё при первых RC. Так что иди, археоложь над какими-нибудь развалинами. И не переживай, я не расстроился. Береги нервы.

Ответить | Правка | Наверх | Cообщить модератору

250. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 10-Дек-14, 15:56 
> Баг-репорт написан ещё при первых RC.

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

> не переживай, я не расстроился.

Ну и славненько.

Ответить | Правка | Наверх | Cообщить модератору

224. "Релиз ядра Linux 3.18"  +/
Сообщение от Аноним (-), 09-Дек-14, 18:49 
>В сетевую подсистему внесены оптимизации, направленные на увеличение производительности пакетной передачи данных. ................ Внесённые изменения позволяют добиться обработки полной пропускной способности высокоскоростных сетевых интерфейсов даже на относительно слабом оборудовании (например, на обычном компьютере продемонстрирована обработка потока в 40 гбит/сек), даже если в трафике преобладают пакеты небольшого размера;

Ждём это в OpenWRT.

Ответить | Правка | Наверх | Cообщить модератору

234. "Релиз ядра Linux 3.18"  –1 +/
Сообщение от Аноним (-), 10-Дек-14, 07:24 
> В утилиту "ip" добавлена новая команда

с каких пор "утилита ip" входит в ядро?

Ответить | Правка | Наверх | Cообщить модератору

236. "Релиз ядра Linux 3.18"  +1 +/
Сообщение от Andrey Mitrofanov (?), 10-Дек-14, 11:27 
>> В утилиту "ip" добавлена новая команда
> с каких пор "утилита ip" входит в ядро?

В iproute2 и iptables регулярно добавляют поддержку появляющихся в новых ядрах возмодностей. Как и в любые другие интерфейсные утилиты и библиотеки.

Ответить | Правка | Наверх | Cообщить модератору

251. "Релиз ядра Linux 3.18"  +2 +/
Сообщение от Аноним (-), 10-Дек-14, 15:57 
> с каких пор "утилита ip" входит в ядро?

Она является фронтэндом к фичам ядра :)

Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру