BFQ (какой патч накладывать?)

http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php

You may apply these patches in a git Linux tree with git am. For example, to add the last bfq version to mainline 3.9.0 starting from scratch:

RELEASE=3.10.0-v6r2 # the release you want
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux
cd linux
git checkout -b the-name-you-like desired-source-kernel-release
wget -nd --no-parent --level 1 -r -R "*.html*" --reject $RELEASE \
    http://algo.ing.unimo.it/people/paolo/disk_sched/patches/$RELEASE
git am *BFQ*.patch

Всегда ваш КО

А если не Гит-ом ?

А если не Гит-ом ?

А есть разница чем накладывать? Или там по тому коду неясно какие конкретно патчи накладываются?

Ага, спасибо, понял - все 3, т.к. шаблон: git am *BFQ*.patch

http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.11.0-v6r2/

ТС советую обратиться к окулисту.

Хе, три штуки наложил. :)

xoomer а на будущее озвучивай хотя бы дистрибутив.

Потому что, к примеру, мне в gentoo достаточно сделать:

layman -a init6
USE="bfq" emerge geek-sources

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

Дай угадаю? Gentoo handbook?^_^

Дистр - openSUSE.

Если бы, уважаемые, еще подсказали как в openSUSE делать в консоли действие аналогичное ортодоксальному update-grub? А то grub обновляю с помощью YaST.

Дай угадаю? Gentoo handbook?^_^

Не угадал.

Дистр - openSUSE.

Тогда прости но you do it wrong!

Ибо сначала man rpm, man rpmbuild затем разуваем глазки на это чудо берем любую нужную версию добавляем чего не хватает и собираем из спека в src.rpm а затем и в rpm.

А если я все прованговал верно то ты в данный момент уже на пути к слаке!

Дистр - openSUSE.

Лучше ничего там не трогай, геморрою не оберёшься, если руки кривые как у меня.

P.s. Слаку ставь там единственный геморрой-разруливать зависимости.

Ребятки, мне надо лишь абы нетбук шустро работал: BFS уже в ядре, сейчас вот вторую свою версию с BFQ компилю.

То есть, зачем мне вот то чудо?

П.С. Приходит на ум, что AppArmor наверное не будет работать в ваниле?

То есть, зачем мне вот то чудо?

Я не знаю… Но в принципе, если ты вменяемый человек, то ты должен понимать что если в ядре suse всяко больше сотни патчей то наверное это все не просто так. И скорее всего если ты вместо того ядра которое задумано дистростроителями suse влепишь ванилу со своими патчиками то как минимум ни к чему хорошему это не приведет. А решать тебе.

А решать тебе.

Значит решать либо рулить к «тому чуду», либо как говорит kinik - на Слаку, либо на Gentoo.

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

Спасибо за help.

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

Возьми src.rpm нужной версии ядра. Исправь его спек и добавь нужные тебе патчи. Обратно собери из спека src.rpm и rpm и юзай.

А метод слаки т.е. ванильное+свои патчи на suse и подобных ей дистрах чреват многими забавными багами. И методом слаки не стоит делать еще и потому что иначе rpm/YaST не будет знать о том какое у тебя ядро. А это на rpm-based дистрах не есть хорошо.

Если бы, уважаемые, еще подсказали как в openSUSE делать в консоли действие аналогичное ортодоксальному update-grub?

# grub2-mkconfig -o /boot/grub2/grub2.cfg #обновит конфиг граба
# grub2-install /dev/sda #переустановит загрузчик

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

Может взять патч, и поглядеть, что там _по_смыслу_ патчится?

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

Один раз научишься, потом сможешь постоянно накладывать (и для других людей выкладывать!)

Давай сюда построчный комментарий что делает код в этом патче.

какая разница?

Юкакая разница? Действительно: одним голословным генератором текста на лоре больше, одним меньше.

ты патч-то смотрел? Там огромные куски нового кода, который достаточно просто скопипастать в любое место, и патчи к готовым функциям, в которых стопудов ничего существенно не поменялось. Что он там делает на самом деле - неважно)

А почему нельзя просто установить сорцы ядра с патчами от SUSE, и туда наложить BFQ и BFS?

Соб-сно, я так уже попытался и выходят ошибочки уже с патчиком BFS.

2derlafff: Спасибо!

Кстати, как у BFQ с оптимизацией позиционирования головок?

И чем собственно CFQ не угодил?

Кстати, как у BFQ с оптимизацией позиционирования головок?

Без понятия, но вот здесь
http://algo.ing.unimo.it/people/paolo/disk_sched/description.php говорится вот что:
«Low-latency guarantees are preserved also in presence of NCQ.»

У BFQ как я понял меньше задержки, чем у CFQ:
«As a comparison, with CFQ, NOOP, DEADLINE or SIO, and under the same conditions, applications experience high latencies, or even become unresponsive until the background workload terminates (especially on SSDs).» ( http://algo.ing.unimo.it/people/paolo/disk_sched/ )

А почему нельзя просто установить сорцы ядра с патчами от SUSE, и туда наложить BFQ и BFS?

А потому что установка из сырцов на rpm-based дистре это прямой путь в слаку.

У BFQ как я понял меньше задержки, чем у CFQ:

Ну вот я и спрашиваю чем это достигается.

Если правильно помню, CFQ выстраивает очередь запросов к диску так чтоб головка проходила нужные секторы последовательно 3>14>123>124>125>234, а не те которые выше в очереди 124>3>123>234>14>125, в итоге износ.

Вот и спрашиваю, кто использовал, может просветить на эту тему?

Получается, если хочешь последние месу, кеды, ядро, свой набор патчей, вайн, то путь лежит в генту?

Можно в двух словах о чем man rpmbuild ?

головка проходила нужные секторы последовательно 3>14>123>124>125>234, а не те которые выше в очереди 124>3>123>234>14>125

Так это, если я правильно понимаю, реализуется в какой-то мере механизмом NCQ, аппаратной фичей HDD.

Получается, если хочешь последние месу, кеды, ядро, свой набор патчей, вайн, то путь лежит в генту?

Получается, если хочешь последние месу, кеды, ядро, свой набор патчей, вайн и все это во первых грамотно а во вторых в SuSE то путь сначала в man rpm затем в man rpmbuild {исправляешь/бампаешь} спеки по ним собираешь src.rpm из которых уже собираешь rpm под свою архитектуру. И вот юзать нужно уже те самые собранные rpm.

Но ни в коем случае не собирать из сырцов (ака „путь слаки“)! Плохо в этом то, что rpm никакого понятия не будет иметь о том, что ты там наустанавливаешь. А это очень и очень плохо потому что у тебя таки rpm-based дистр.

Так это, если я правильно понимаю, реализуется в какой-то мере механизмом NCQ

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

http://www.opennet.ru/base/sys/ioshedulers.txt.html

   Сортировка, более важная из этих двух операций,- это процесс упорядочивания запросов
   ввода/вывода в восходящем порядке номеров блоков. Например, если есть операции ввода/вывода
   с блоками номер 52, 109, и 7, то планировщик ввода/вывода будет сортировать эти запросы в
   порядке 7, 52 и 109. Если запрос был выдан на блок 81, он будет вставлен между запросами на
   блоки 52 и 109. Планировщик ввода/вывода направит запросы к диску в том порядке, в котором
   они стоят в очереди: 7, затем 52, затем 81, и, наконец, 109.

Вобщем хочется что-бы кто-то высказал авторитетное мнение на тему best practices: io scheduler vs NCQ

хотя-бы в двух словах - что такое спеки?
дайте зацепку, плз!

src.rpm собирать совершенно не обязательно

1. rpm -i <package>.src.rpm (от юзера) - ставит сорсы и спеки в ~/rpmbuild

2. Добавляешь патчи в ~/rpmbuild/SPECS/<package>.spec и сами патчи в ~/rpmbuild/SOURCES/

3. rpmbuild -bb ~/rpmbuild/SPECS/<package>.spec

что такое спеки

Установи src.rpm и поизучай, см. коммент выше. В кратце - декларативное описание способа сборки пакета, включая накладываемые патчи, плюс метаданные (автор, зависимости и т.д.)

Ты это не мне говори а вон xoomer-у ;)

А ты начинай читать man-ы.