Подскажите на каких задачах эффективен двухканальный режим DDR?

Вряд ли.

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 4194304

Ядро - последнее из репов,

распаковываю ~50 G .tar.gz с винта на винт.

8G рамы и столько же свопа.

у меня никогда раньше небыло подобных проблем и я в некотором замешательстве

двухканальный режим DDR?

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

Многочисленные тесты опровергают твои категоричные слова.

8G рамы и столько же свопа.

Чему равен параметр sysctl vm.swappiness? И да, а зачем при 8 гигах памяти своп? Очень тяжелые приложения крутишь?

А засыпать куда?

Упс, посыпаю голову пеплом, совсем забыл что у ТСа - ноутбук. Вопрос снимается.

Чему равен параметр sysctl vm.swappiness?

60

Очень тяжелые приложения крутишь?

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

распаковываю ~50 G .tar.gz с винта на винт.

Просто тормозной винт, это же ноут, что ты хочешь?

А засыпать куда?

А отключать своп за ненадобностью и подключать исключительно перед „засыпанием“ не учили?

А при чём тут это? Вне зависимости от того, подключен ли своп постоянно или швартуется только при необходимости, на ноуте он нужен. Если его нет, то и подключать нечего.

что ты хочешь?

например разложить пасьянс пока архив распаковывается

у меня на другом железе никогда небыло подобных проблем.

А при чём тут это?

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

на ноуте он нужен

На ноуте с 8Гб озу нужен свап? Ты упорот возвращайся как попустит.

И вообще заметь разницу между „действительно необходим“ и „иначе ему засыпать некуда… а так охота“.

у меня на другом железе никогда небыло подобных проблем.

Ну дык возьми и выясни что конкретно „тормозит“ на этом железе в твоих условиях. Результат тебя может удивить. Потому что зачастую даже чуть менее чем вообще всё связанное с 12309 „тормозило“ на самом деле по вовсе другим причинам.

это из серии очевидное невероятное. И мне кажется, как то связано с распаковкой и кодом gunzip. Расскажу свою бесполезную историю, просто потрепаться.

Есть сервер 16 ядер Xeon , 24 ram, диски:DAS sas raid60 на 7200 оборотах и ещё iscsi удаленное хранилище. Сжимал с помощью pigz большие образа, по 2ТБ с das на iscsi. Шоколадно, полностью нагруженная система, все ядра, гигабит загружен. при этом никакого странного поведения )

Потом нужно было разжимать в обратную сторону. и тут апзац.

во-первых, один поток, всего 30-40мбайт/с. Причем, gunzip был чуть быстрее pigz -d.

А во-вторых, начались лаги, подлагивают ssh сессии, перестаёт нормально работать io на корневом разделе, не относящемся ни к das, ни к iscsi. И это при нагруженном одном ядре!

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

Ну, разбираться не стал, не моя сфера и задача. Распаковалось и ладно. Но впечатление недосказанности осталось.

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

Хм. сильно похоже.

Ну дык возьми и выясни что конкретно „тормозит“ на этом железе в твоих условиях.

Ок, можешь порекомендовать как это организовать на x86? Я знаю как это провернуть на ARM но на x86 эти инструменты не работают,

кажется, я только что это повторил с cp -R 50-80 wa 20-30 id, даже анимации квина замирают в процессе разворота окна, выглядит довольно неприятно, размыто, и пикселизованно. половина памяти также свободна, хмм правда половина свопа чем-то забита и топ показывал основная нагрузка идет от жирнолиса во время активности cp (мне кажется эти тормоза были связаны с тем, что жирнолис отъел как минимум половину оперативки).

двухканальный режим - маркетинговый булшит.

Я даже на i7-4770 не заметил разницу между одноканальным и двухканальным режимом. А в ноутбуке уж подавно.

Ок, можешь порекомендовать как это организовать на x86?

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

Я знаю как это провернуть на ARM

нет не знаешь

Чушь собачья.

Я даже на i7-4770 не заметил разницу между одноканальным и двухканальным режимом

Потому что ты ничего, кроме контактика, не используешь, лол.

Ядро - последнее из репов,распаковываю ~50 G .tar.gz с винта на винт. 8G рамы и столько же свопа. у меня никогда раньше небыло подобных проблем и я в некотором замешательстве

Бугага, и я еще жаловался на тормоза...

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

С 3.17 стало легче жить

tmpfs

извращенец ты какой