LINUX.ORG.RU
ФорумTalks

[2.6.32] CFQ «low latency» (a.k.a. «desktop») mode


0

0

В ядро 2.6.32 была добавлена поддержка режима «low latency» (изначально назывался «desktop») для планировщика ввода-вывода CFQ (не путать с планировщиком процессов CFS). Причём этот режим включен по умолчанию, специально для пользователей обычных десктопов =).

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

При необходимости, новое поведение можно будет выключить для отдельных блочных устройств через интерфейс sysfs.

Подробности: http://lwn.net/Articles/355904/

Deleted

Возможно баян и тут уже было.

Deleted
()

уже 32, а я до 31 не могу обновиться - мусор сплошной в иксах, что-то с ати сломали чтоли :/

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

volh ★★
()

Linux evy 2.6.32-rc8-bfs311-evy #1 SMP PREEMPT Tue Nov 24 06:12:39 MSK 2009 i686 Intel(R) Atom(TM) CPU 330 @ 1.60GHz GenuineIntel GNU/Linux


что-то вот не заметила что там что-то поменяли c cfq

Sylvia ★★★★★
()
Ответ на: комментарий от Klayman

при том. откатываюсь на .30 - хорошо. обратно на .31 - плохо. все настройки ксорга менял, другие драйверы использовать пробовал.

volh ★★
()

mironov_ivan утверждает что

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

Разве так? Я считал что так себя ведет anticipatory, а cfq просто гарантирует каждому процессу доступ равноценный доступ к диску.

sdio ★★★★★
()
Ответ на: комментарий от sdio

а cfq просто гарантирует каждому процессу доступ равноценный доступ к диску.

Если я правильно понимаю, он тоже пытается оптимизировать порядок запросов. Хотя возможно ошибаюсь.

Deleted
()
Ответ на: комментарий от sdio

вообще пишут что лучше использовать noop, в том случае если диск поддерживает NCQ . только вот я что-то положительного эффекта в производительности не наблюдала, может потому что чипсет nvidia

Sylvia ★★★★★
()

gold

пользуясь случаем (не хочу отдельно создавать тему) , спрошу
ядро уже можно собирать с gold вместо ld ?

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

только вот я что-то положительного эффекта в производительности не наблюдала

Эффект есть. Тормозов на при дисковых операциях ощутимо меньше, нежели с CFQ.

GotF ★★★★★
()
Ответ на: комментарий от GotF

значит вероятно проблема в чипсете, точнее том как ядро с ним работает

nForce 630i (MCP73)

Sylvia ★★★★★
()

Этим планировщиком можно лимитировать i/o wait медленных флешек?

quickquest ★★★★★
()
Ответ на: gold от Sylvia

отвечу сама на свой же вопрос про gold vs linux kernel:

MODPOST vmlinux.o
WARNING: modpost: Found 1 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
GEN .version
CHK include/linux/compile.h
UPD include/linux/compile.h
CC init/version.o
LD init/built-in.o
LD .tmp_vmlinux1
ld: internal error in convert_types, at gold.h:294
make[2]: *** [.tmp_vmlinux1] Error 1

Sylvia ★★★★★
()
Ответ на: комментарий от volh

+1, в 31ом эпичные баги из ниоткуда взялись, благо хоть ребята из Mandriva team пофиксили то, что могло заставить меня надолго остаться на 30 и ниже ядрах

PayableOnDeath
()
Ответ на: комментарий от Sylvia

у меня ноут - единственная рабочая машина. поэтому ставить rc-ядра как-то в другой раз. и так версии аля xf86-video-ati 6.12.99.git20091014-1 стремают. вот когда ты оттестируешь и поставишь штамп «годен», так и сразу.

volh ★★
()
Ответ на: комментарий от linux4ever

мне надоели зависы с 7.7
у меня 7.6rc1 , kms на .32 не работает с моей картой, вешается на загрузке firmware, с .31 kms работал, но так или иначе приводит к завису через несколько часов. Так что про новости с r300 и last-minute-git меня можно не спрашивать, принципиально лучше пока не будет (для меня принципиально лучше это увеличение стабильности и добавление новых расширений OpenGL)

Sylvia ★★★★★
()

Что только не сделают лижбы BFQ не принимать =)))

Freiheits-Sender ★★
()
Ответ на: комментарий от Sylvia

>>2.6.32-rc8-bfs311

Ух, отлично, хотет такое :( Надо будет сейчас поискать в арчерепах.

Дрова нвидиевские работают на этом?

nutz ★★
()
Ответ на: комментарий от nutz

нвидиевские работают


190.42 нет , я не спешу обновлять десктоп, не резон ) на нем итак все работает.

Sylvia ★★★★★
()

CFQ бяка, старый добрый anticipatory рулит.

nu11 ★★★★★
()
Ответ на: gold от Sylvia

>ядро уже можно собирать с gold вместо ld ?

А что это такое и какой profit оно даёт?

iZEN ★★★★★
()
Ответ на: комментарий от Quasar

Инго Молнар продолжает насиловать труп.

Повторяю: не путайте планировщик ввода-вывода с планировщиком процессов. Это разные вещи, они выполняют разные функции и разрабатывают их разные люди.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.