| 1.3, Аноним (-), 12:01, 30/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– | |
Не использовал патчи -ck для < 2.6.22 так как ещё не умел, но был о них очень наслышан. К моменту, когда перешёл на Gentoo, вышел BFS. Установил - и YouTube стал идти плавнее. BFS - нужен! Если у вас меньше 16-ти физический ядер, то нужен однозначно!
MuQSS? Щас затестю :-) Говорят, CFS с тех времён подтянули до уровня BFS (конкуренция, фигле), что ж глянем на предмет революции в планировщиках :-) На производительность не жалуюсь правда - в тот раз был Pentium IV, тихий ужос скажу я вам. Я слишком поздно узнал, что всю первую половину 00-х AMD был лучше.
| | |
| |
| 2.5, Аноним (-), 12:15, 30/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
А ты сейчас BFS используешь? Просто если суддить по тексту новости, то профит есть только на Атомах, Athlon Neo и прочих одноядерных компах. Не сводится ли всё на нет при 2+ ядрах?
| | |
| |
| 3.18, Ksevros (?), 14:56, 30/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
На самом деле, на одноядерниках как раз и нет профита от BSF, наоборот только хуже становится. При запуске почти любого приложений система подвисает на 1-2 секунды (мышь становится неуправляемой), на CFQ такого не наблюдается. Это из личного опыта.
| | |
| |
| |
| |
| 6.36, Аноним (-), 19:46, 30/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Только речь о планировщиках задач, а не I/O.
Ты ему только не говори что еще и планировщики сети бывают, а то он сойдет с ума :)
| | |
|
|
|
|
| 2.23, Аноним (-), 17:19, 30/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
"YouTube стал идти плавнее" - после такого, можно вообще не читать ваше сообщение.
| | |
| |
| |
| 4.37, Аноним (-), 19:47, 30/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Что такого?
То самое: метрика из разряда "волосы стали на 20% шелковистее". Простите, а в каких единицах измеряется шелковистость волос и плавность ютуба?
| | |
| |
| 5.41, Michael Shigorin (ok), 20:07, 30/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 > Простите, а в каких единицах измеряется шелковистость волос и плавность ютуба?
Вы для начала определили бы, в каких единицах измеряется пригодность сообщения к прочтению, а то как-то демагогией отдаёт за версту.
PS: по существу: видимо, "на глазок" -- или есть заметные дёрганья, или нет/редко.
| | |
| |
| 6.47, Аноним (-), 20:35, 30/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Человеку правильно все сказали, наверное намекая что "на глазок" - не является хорошим инструментом. К тому же в силу склонности двуногих к эффекту плацебо ютуб может стать плавнее, а волосы шелковистее даже если в коде ничего не менять и дать пожевать прессованый мел. Поэтому таким заявлениям грош цена без инструментированных метрик, да и запустить latencytop до выдачи громких заявлений - не очень сложная наука.
| | |
| |
| 7.67, Аноним (-), 07:31, 01/11/2016 [^] [^^] [^^^] [ответить]
| +/– |
при всем уважении, речь не об эффекте плацебо, а о самообмане
эффект плацебо имеет эффект, а самообман — нет
| | |
| 7.74, Аноним (-), 19:06, 02/12/2016 [^] [^^] [^^^] [ответить]
| +/– |
Как попробовавший сабж в составе Liquorix, могу сказать, что разница действительно видна, причем вне зависимости от VDPAU и вообще не только при просмотре видео. Например, при всех ядрах загруженных кодированием x265 прокрутка в Firefox остается почти такой же плавной, как при свободном CPU. Анимации KDE тоже более плавные. Я хз в каких единицах измеряется плавность, но эффект есть, это факт. (Core i7 2600K. Железо и софт в ходе экспериментов не менялись, только ядро).
| | |
|
| 6.65, Аноним (-), 17:35, 31/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Дёрганья на ютубе -это или протухший комп или замечательный свободный видеодрайвер (нуво как раз вот такой) или оба два сразу. Это к бабке не ходить! И на планировщик тут вообще нечего кивать.
| | |
|
| 5.58, Аноним (-), 09:03, 31/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
В чём измеряется шелковистость волос не знаю. А вот плавность можно измерять в FPS.
| | |
|
|
|
|
| 1.4, Аноним (-), 12:06, 30/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Больше нет слова Fuck в названии? Можно надеяться на включение в ядро :-)
| | |
| |
| |
| |
| 4.49, Аноним (-), 20:49, 30/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Да, это само по себе хорошо характеризует автора в наши дни :o)
Ну тогда ваш любимый openvz - просто кошмарище, потому что без такого управления ресурсами он вообще будет ни о чем.
| | |
| |
| 5.51, Аноним (-), 22:24, 30/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
openvz сам по себе кошмар, что с управлением ресурсами, что без.
Особенно сейчас с их идиотской манерой разработки, одни патчи есть в этой ветке.. другие патчи только в этой..
и конфигурируй как хочешь..
| | |
| |
| 6.54, Аноним (-), 00:52, 31/10/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> openvz сам по себе кошмар, что с управлением ресурсами, что без.
Спору нет, просто без управления ресурсами в духе того что сейчас cgroups обеспечивают - их продукт вообще не взлетел бы и мы бы его вообще не обсуждали.
> Особенно сейчас с их идиотской манерой разработки, одни патчи есть в этой
> ветке.. другие патчи только в этой..
> и конфигурируй как хочешь..
Я уже сконфигурировал все что мне было надо без них. Не нравится мне когда системное администрирование превращают в порнографию, поэтому я как-нибудь обойдусь без этой чудной компании с чудными продуктами. Пусть они там как-нибудь сами пользуются своими дистрибутивами и черти-какими ядрами.
| | |
|
|
|
|
|
| |
| 2.31, Аноним (-), 18:58, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– | |
> Пишите сюда кто использует Brain Fuck Scheduler и почему ? )
Потому что кто-то любит плацебо? Или "увеличение" производительности в несколько сотых процента?
| | |
| |
| 3.68, Аноним (-), 07:34, 01/11/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
плацебо — пустышка, которая приводит к положительному эффекту, а не то, что Вы подумали
| | |
|
| 2.33, anono (?), 19:19, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Я юзал издавна и юзаю уже по привычке. Пробовал на атлоне двухъядерном, тема крутейшая. как раз на нём и видишь, что youtube работает "плавнее". А если быть точным, то фулл хд работал на фулскрине хорошо и не проседал фпс, хотя комп был довольно скромный. Меньше лагов и лучше производительность
| | |
| |
| 3.35, Аноним (-), 19:34, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Измерять производительность по тытрубе -- верх идиотизма. Вот когда предоставишь результаты тестирования, например, компилирования в несколько потоков с MuQSS и без, тогда поговорим. Я пока разницы не заметил, железо не самое мощное. Кстати говоря, по моему даже 3.16 работает, субъективно, побыстрее. Проверить пока времени не было.
| | |
| |
| 4.39, anono (?), 19:56, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Измерять производительность по тытрубе -- верх идиотизма. Вот когда предоставишь результаты
> тестирования, например, компилирования в несколько потоков с MuQSS и без, тогда
> поговорим. Я пока разницы не заметил, железо не самое мощное. Кстати
> говоря, по моему даже 3.16 работает, субъективно, побыстрее. Проверить пока времени
> не было.
а как можно увеличить производительность одного и того же железа? фпс не проседал просто потому, что приоритет отдавался больший этому процессу, планировщик распоряжался ресурсами в соответствии с потребностями десктопа. Хочешь тесты и диаграмки -- проведи их сам. С компилированием вообще насмешил, конечно, прирост может быть, но с одним и тем же компилятором и винтом ты вряд ли увидишь разницу больше пары процентов
| | |
| |
| 5.43, Аноним (-), 20:09, 30/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Я просто пример реальной задачи, которой реально нужно распределение ресурсов привёл. Твоему ютьюбу точно это не поможет, там уж скорее от браузера зависит. И потом от разных планировщиков получаешь некий гипотетический прирост, когда есть несколько распределённых процессов. Особенно это видно на многоядерных процессорах, когда например 4 процесса распределяются по ядрам, а не висят все на одном, безбожно при этом тормозя.
| | |
| |
| 6.57, Анонимный (?), 08:49, 31/10/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вы не можете понять прочитанное в новости. Планировщик заточен под десктопные задачи. Компилирование чего либо сложно отнести к таковым. Достигаемые цели лежат в разных плоскостях.
А вот ютюб вполне себе типичен для десктопа. И никакое "там уж скорее от браузера зависит" в данном случае тут не причем. Просто планировщик должен каким-то образом равномернее загружать ядра. Если при этом на глаз заметно, что ютюб стал работать без рывков, то эффективность планировщика на лицо. Разумеется, что, если процессор априори слаб для воспроизведения видео, то тут никакой планировщик не поможет.
| | |
|
|
|
|
| 2.62, dangerenok (?), 12:10, 31/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Раньше использовал, месяца 4. Визуально не заметил ускорения. Проводил бенчмаркинг игры ради которой заморачивался с ним - оказалось стало хуже. Может не то что-то накрутил, хз. Слишком тонкие для меня материи.
| | |
|
| |
| 2.10, safsad (?), 13:33, 30/10/2016 [^] [^^] [^^^] [ответить]
| +11 +/– |
Смысл не понимай, хрень понаписай. 12309 связан с I/O элеваторами, а не процессорными.
| | |
| |
| |
| 4.38, Аноним (-), 19:54, 30/10/2016 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> не факт
Вообще-то факт: для процессорного планировщика чисто технически сложно вклинить систему настолько что гораздо более медленный двуногий вообще заметит лаги.
Особенно в 1000 Hz ядрах, где kernel preemption разрешен. Если уж кого латенси парит, вот эту сладкую парочку стоит первым делом проверить. Ну как, если кернел пойдет запрос обрабатывать и встрянет на пару секунд при этом - весь мир таки подождет. Или по крайней мере ощутимая его часть. А если кернел сам себя preempt'нет и продолжит туповэйтинг или что там у него когда-нибудь потом - остальным ждать не придется.
| | |
|
| 3.13, Аноним (-), 14:16, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Не связан он с I/O элеваторами. С page cache и vm вообще связан.
| | |
| |
| 4.29, Аноним (-), 18:50, 30/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Уверен? Может ты ещё и разработчик ядра? Никто это починить не может уже много лет, а ты так вот говоришь, как будто точно знаешь. А если знаешь, почему разрабам не сказал или сам патч не написал? Все бы тебе благодарны были только.
| | |
| |
| 5.40, Аноним (-), 20:01, 30/10/2016 [^] [^^] [^^^] [ответить] | +5 +/– | Вообще он все правильно написал Оригинальный 12309 был связан с тем как работае... большой текст свёрнут, показать | | |
| |
| 6.44, Аноним (-), 20:11, 30/10/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Именно 12309 был починен несколько лет назад.
Якобы. А у меня и ещё одного человека, которого я лично знаю, он продолжает проявляться.
| | |
| |
| 7.46, Аноним (-), 20:28, 30/10/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Якобы. А у меня и ещё одного человека, которого я лично знаю,
> он продолжает проявляться.
Может быть, стоит прекратить ламерствовать и осознать что одинаковые проявления "система тормозит" могут скрывать в себя бесконечное множество самых разных багов? И это не является 12309. Это какой-то другой баг с похожими проявлениями.
И таки да, если вы не будете писать баги или будете оформлять их как бакланы, с описанием "система тормозит" - никто их не починит. Потому что никто не узнает. А если и узнает то не сможет воспроизвести у себя. Ну и говоря за себя - почему-то линуксные разработчики зашибли довольно много багов которые повесил им я. Но я мог описать проблему и знал кого из разработчиков пнуть, чтобы все заверте...
| | |
| 7.48, Led (ok), 20:40, 30/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
 >> Именно 12309 был починен несколько лет назад.
> Якобы. А у меня и ещё одного человека, которого я лично знаю,
> он продолжает проявляться.
Ты и твой одноклассник - лузеры.
| | |
| 7.52, Аноним (-), 23:35, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Ну так потюнь vm.dirty_background_ratio / vm.dirty_ratio, чтобы минимизировать вероятность возникновения ситуаций, когда сброс страничного кэша становится синхронным. А лучше купи себе побольше памяти.
| | |
| |
| 8.56, Аноним (-), 07:50, 31/10/2016 [^] [^^] [^^^] [ответить] | +/– | Ну конечно, купила-притупила Чтобы купить побольше памяти, мне понадобится купи... текст свёрнут, показать | | |
| |
| 9.70, Stax (ok), 14:12, 02/11/2016 [^] [^^] [^^^] [ответить] | +/– |  Одна память не поможет У меня 16 Гб и своп на SSD - используется крайне редко,... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 1.15, fidaj (ok), 14:18, 30/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 пробовал BFS на ранних стадиях его разработки - устраивал вполне.
потом начали химичить - стало совсем плохо со стабильностью, потом стали частыми фризы.
положение дел не изменялось от версии к версии.
потом попробовал MuQSS - все еще хуже - уж слишком оно сырое и бажное.
на 4.8.5 вполне теперь нормально работает дефолтный планировщик (касаемо интерактивности при большой нагрузке), правда на самосборном ядре.
| | |
| |
| 2.30, Аноним (-), 18:52, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
У меня и BFS и MuQSS работают нормально начиная с 4.х ядра. Но и улучшений я не вижу. Видимо это варьируется от железа к железу.
| | |
|
| 1.24, Ape (ok), 17:22, 30/10/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 А, для SSD только NOOP годится сегодня? Или есть другие планировщики для десктопа с учётом особенностей SSD?
| | |
| |
| 2.45, Аноним (-), 20:21, 30/10/2016 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> для SSD только NOOP
Не тестировал, но наверное есть смысл заморочиться с тонким тюнингом CFQ. По идее там надо сотни миллисекунд превратить в единицы/десятки миллисекунд. В теории должно выходить лучше, чем "очередь команд не более 31 операции" на уровне SATA+noop/blk-mq.
| | |
| |
| 3.50, Аноним (-), 21:04, 30/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Пресловутый похороникс недавно как раз тестировал. И там получилось достаточно разнобойно. В одних тестах лучше одно. В других другое. А еще эти тесты не меряли латенси. А как известно, latency и bulk performance - две разных стороны медали. А чтобы bulk performance уживался с low latency - это почти философский камень системных архитектур.
| | |
|
| 2.59, Аноним (-), 11:07, 31/10/2016 [^] [^^] [^^^] [ответить]
| +/– |
Для SSD есть blk-mq, но это не планировщик, а фактически альтернативный block layer. Планировщик для него вроде бы еще не сделали.
| | |
|
| 1.71, Аноним (-), 16:40, 05/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Пропатчил сейчас 4.8.5 новеньким MuQSS. Система реально стала отзывчевее, конкретно: хром стал быстрее запускаться.
| | |
| |
| 2.72, xpue (ok), 18:02, 06/11/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Похоже на плацебо/изменение несвязанных параметров, запуск хрома это io-bound задача.
| | |
|
| 1.73, Аноним (73), 20:18, 06/11/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 linux-liquorix (4.8-8) unstable; urgency=medium
* merge 4.8.6
+ * merge BFQ v8r5
* remove writeback throttling patches (cfq, bfq, block)
* merge only softirq patches from MuQSS v135
* update version to 6.1
| | |
|
