LINUX.ORG.RU

Вышел патчсет от Кона Коливаса

 , kolivas, patchset,


0

1

Вышел патчсет для ядра 2.6.32 от Кона Коливаса.

Коливас — в прошлом один из активных разработчиков ядра (анестезиолог по образованию, им же и работает), который привносил свежие идеи, улучшающие работу ядра Линукса на обычных десктопах. К сожалению, в своё время, ни его планировщик процессов SD, ни технология упреждающего своппинга (swap prefetching) не встретила одобрения со стороны «власть имущих» (т. е. Торвальдса), в связи с чем Коливас самоустранился от работ в области ядра.

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

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

Хочется надеяться, что в ближайшем будущем наработки Коливаса будут включены в основное ядро.

>>> Скачать патчсет

★★★★★

Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)

Ответ на: комментарий от anonymous

>НУ ДОКОЛЕ МНЕ ЭТУ СРАНЬ ТЕРПЕТЬ??!!!

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

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

> Чтобы понимать толк в омлете не нужно быть курицей.

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

twoflower
()
Ответ на: комментарий от pekmop1024

> Попробвал :) пришлось ждать окончания создания образа, т.к. даже на Ctrl+Alt+F1 не реагировал. :) Без выключения APIC я хотя бы мог отмену жмакнуть и через секунд 30 она срабатывала. А тут - даже окошко не успело отрисовать.

планировщик i/o сменить на anticipatory или noop
отключить ncq: echo 1 > /sys/block/sda/device/queue_depth
это должно помочь....

anonymous
()
Ответ на: комментарий от B3ND3R

> Кстати, есть ли для 2.6.32 отдельно патч bfq?
У меня есть.

Lumi ★★★★★
()

мда... kernel/posix-cpu-timers.c: In function ‘check_thread_timers’: kernel/posix-cpu-timers.c:1048: error: ‘struct task_struct’ has no member named ‘rt’ kernel/posix-cpu-timers.c:1049: error: ‘struct task_struct’ has no member named ‘rt’ CC arch/x86/kernel/cpu/intel_cacheinfo.o make[2]: *** [kernel/posix-cpu-timers.o] Ошибка 1 make[2]: *** Ожидание завершения заданий... make[1]: *** [kernel] Ошибка 2 make[1]: *** Ожидание завершения заданий...

omfg2
()
Ответ на: комментарий от mcdebugger

>WTF??

Ну забей acpi_os_name=“Microsoft Windows” в гугль и прочти! Как же достали ленивые существа.

«Я плАчу, когда меня окружают глупые люди» (с) Шелдон Купер

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

>при чем тут ACPI вообще не понятно

Прерывания, детка, прерывания. Одна из причин тормозов при IO. Именно acpi бывает тут причём. Ты просто не сталкивался.

anonymous
()

Кон Коливас - Тотем Криворуких Баранов.

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

>не пори чушь, какие нахрен прерывания???

Status:     RESOLVED INSUFFICIENT_DATA

Не намекает? Синдром вызывается тучей причин и не диагностируется. Одной из причин, отловленной и устранённой мною лично, был кривой ACPI. Вылечил путём декомпиляции и исправления таблицы. Спасибо гентушому форуму. И некоторым «Microsoft Windows» помогает. А все приведённые советы в этом баге суть пляски с бубном, маскирующие странную, не поддающуюся анализу проблему.

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

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

$ cat /proc/interrupts 
           CPU0       CPU1       
  0:   17819067   17286715   IO-APIC-edge      timer
  1:      43659      42852   IO-APIC-edge      i8042
  8:         28         31   IO-APIC-edge      rtc0
  9:    1230697    1230563   IO-APIC-fasteoi   acpi
 12:       1032       1029   IO-APIC-edge      i8042
 14:      63614      62515   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:    1000922     954964   IO-APIC-fasteoi   uhci_hcd:usb3, nvidia
 17:        930        906   IO-APIC-fasteoi   mmc0, firewire_ohci
 18:          0          2   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb7
 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb6
 21:     980272     947571   IO-APIC-fasteoi   uhci_hcd:usb4, HDA Intel
 23:          0          0   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb5
 30:     731218     723751   PCI-MSI-edge      ahci
 31:   12563240   12559800   PCI-MSI-edge      eth0
 32:          0          0   PCI-MSI-edge      iwl3945
NMI:          0          0   Non-maskable interrupts
LOC:   17877734   18510713   Local timer interrupts
SPU:          0          0   Spurious interrupts
CNT:          0          0   Performance counter interrupts
PND:          0          0   Performance pending work
RES:    5133838    4854861   Rescheduling interrupts
CAL:     837755     830796   Function call interrupts
TLB:     164328     111724   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:        392        392   Machine check polls
ERR:          0
MIS:          0

вот кусок dmesg-а http://paste.pocoo.org/show/159057/

спасает отключение ncq (сильно) и cfq (немного)

куда копать, как считаешь?

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

Полный dmesg на pastebin положи? Таблица выглядит вменяемо, я бы нвидию и звуковуху на msi перетащил. modprobe nvidia NVreg_EnableMSI=1 и modprobe snd-hda-intel enable_msi=1

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

Выглядит глюк у тебя так. При копировании с на винт IOwait 100% и аццкие лаги гуя? У меня такое случилось при копировании с на триваревский райд. Вылечлилось

echo 5 > /proc/sys/vm/dirty_background_ratio

echo 1024 > /sys/block/sda/queue/read_ahead_kb

echo 256 > /sys/block/sda/queue/nr_requests

echo 128 > /sys/block/sda/device/queue_depth

Шедулер cfq. Вишка в том, чтобы nr_requests было _больше_ чем queue_depth. По дефолту наоборот.

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

>ACPI Warning: Incorrect checksum in table [OEMB] - B9, should be E4 20090521 tbutils-246

Ну вот это как минимум намекает нам, что табличку было бы неплохо разобрать собрать и посмотреть на варнинги.

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

>Как же достали ленивые существа.
Так лень объяснить?

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

> Ну вот это как минимум намекает нам, что табличку было бы неплохо разобрать собрать и посмотреть на варнинги.

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

Выглядит глюк у тебя так. При копировании с на винт IOwait 100% и аццкие лаги гуя?


Угу

Шедулер cfq. Вишка в том, чтобы nr_requests было _больше_ чем queue_depth. По дефолту наоборот.


queue_deph по дефолту 31, то есть это максимально-возможное значение
nr_requests по дефолту 128, то есть и так больше. Спасает хоть как-то установка очереди вообще в 1

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

Погуглил, в общем-то натолкнулся на то, чего и ожидал.
Но это не повод к тыканию в поисковик.
Более того. Может мне расовые предрасположенности запрещают использовать гугл, а? Сбор конфиденциальной информации и пр. На ЛОРе стали частенько об этом говорить...

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

>Initializing cgroup subsys cpuset

Initializing cgroup subsys cpu

Это тебе нужно? Используешь cpusets? Как и зачем, если не секрет?

KERNEL supported cpus:

Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU UMC UMC UMC UMC

Зачем тебе столько архитектур?

Clocksource tsc unstable (delta = -230074963 ns)

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

В студию.

Больше криминала не вижу... Покажи hdparm -iI /dev/sda

anonymous
()
Ответ на: комментарий от mcdebugger

Ты не поверишь. После Nного раза - лень. Всё уже объяснено до нас.

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

Эта. И попробуй 2.6.32. Мне докладывали об излечении. Попробуй clocksource hpet выставить. Похожий интель с tsc весь мозг изъебал.

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

> ненене. Это не тот queue который в ncq! Это queue cfq!

как не тот? тот самый ))

Это тебе нужно? Используешь cpusets? Как и зачем, если не секрет?


это для виртуализации. libvirt ложит каждый qemu в cgroup...

Зачем тебе столько архитектур?


я честно говоря даже хз откуда оно пролезло. вроде через menuconfig не видно такого зоопарка. потом гляну, по всей видимости включил что-то ненужное ))

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

cat /sys/devices/system/clocksource/clocksource0/current_clocksource


В студию.



hpet и acpi_pm стоит hpet
да это к делу не относится, это трабла специфичная для microstar и еще некоторых вроде...

Эта. И попробуй 2.6.32. Мне докладывали об излечении. Попробуй clocksource hpet выставить. Похожий интель с tsc весь мозг изъебал.


hpet автоматом ставится...
в .32 у меня полная жопа с ACPI. там у них регрессия в AC-драйвере с некоторыми материнками MSI. в 29-31 они хз сколько фиксили, а до .32 пока вообще не добрались. у меня THRM показывает 170 а AC вообще 3214354%, lol! )))

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

Мда. Трудное железо...

как не тот? тот самый ))

Сейчас в код и гугль полезу. Значение по дефолту оно из размера ncq брать вполне может... Я вот что то не уверен... Знаю были косячные винты с кривым ncq. Не твой случай? По марке винта + ncq не гуглил?

это для виртуализации. libvirt ложит каждый qemu в cgroup...

Спасибо. Как раз планирую kvm с qemu помучить.

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

Слухай. А вот в голой текстовой консоли без фреймбуффера при копировании тоже лаги есть? Проверял? А то iowait 100% в принципе штатная вещь, но к дерготне приводить не должна. Может у тебя при IO видюха лочится?

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

> Сейчас в код и гугль полезу. Значение по дефолту оно из размера ncq брать вполне может... Я вот что то не уверен... Знаю были косячные винты с кривым ncq. Не твой случай? По марке винта + ncq не гуглил?

Это уже третий винт в этом ноуте - везде тормоза. Так что не думаю...

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

И всё это очень похоже на кривой acpi bios всё же... Видел много странной мистики на эту тему. Самое то место для подземного стука. Там выше ссылочка была на всякие параметры ядру на тему acpi. Поиграйся, и если внезапно отлечится баг - ты знаешь где косяк ))

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

> Слухай. А вот в голой текстовой консоли без фреймбуффера при копировании тоже лаги есть? Проверял? А то iowait 100% в принципе штатная вещь, но к дерготне приводить не должна. Может у тебя при IO видюха лочится?

Один хрен похоже..

Да и без ncq и cfq wait примерно на уровне 60%

вот самый тяжелый случай (копирую 5 гиг):

2 4 216 14896 78720 755732 0 0 20244 11676 1666 1192 3 16 12 68
0 3 216 17252 78748 753304 0 0 14992 18112 1460 1066 5 14 14 68

стоит включить cfq и пудет полная хана

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

это был вывод vmstat

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
2 4 216 14896 78720 755732 0 0 20244 11676 1666 1192 3 16 12 68
0 3 216 17252 78748 753304 0 0 14992 18112 1460 1066 5 14 14 68

то есть без cfq жизьнь вполне терпима ;)

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

>то есть без cfq жизьнь вполне терпима ;)

Так то она так... Только отрубание cfq маскирует какой то более глубинный баг. Вот рядом машинка-десктоп, не ноут, тоже микростаровская, похожа по железу на твою, правда 64 бита. Бага нет. Попробуй всё же с acpi поиграть. Всё же есть мистика какая то.

anonymous
()

Возвращение блудного анастезиолога или Анастезиолог наносит ответный удар

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

> Так то она так... Только отрубание cfq маскирует какой то более глубинный баг. Вот рядом машинка-десктоп, не ноут, тоже микростаровская, похожа по железу на твою, правда 64 бита. Бага нет. Попробуй всё же с acpi поиграть. Всё же есть мистика какая то.

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

2.6.26-27 у меня кстати летают и с CFQ.. И с ACPI-EC все гуд.. Может таки действительно acpi...


anonymous
()

Спасибо, давно не видел, как машина виснет наглухо через 30 секунд после загрузки.

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

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

неужели? а может достаточно вставить #define?

ну вот и вставь, раз такой умный

thrall
()
Ответ на: комментарий от post-factum

А, извиняюсь, я ваше сообщение неправильно понял прочитал

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

А Вы в курсе, что Вы звезда по имени Солнце? Поначалу привлекаете взор, а потом слепите и хочется чтобы Вы скорее закатились.

anonymous
()
Ответ на: комментарий от goingUp

То, что тут так часто упоминается слово анастезиолог - это такой тонкий намек на то, что у него есть доступ к закиси азота?


Оксибутират...

deis
()
Ответ на: комментарий от anonymous

>echo 1024 > /sys/block/sda/queue/read_ahead_kb

Ого! Я как-то не уверен что от этого стало лучше, скорее очень даже наоборот.

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

Издержки слепой печати не глядя в монитор

DNA_Seq ★★☆☆☆
()

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

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