LINUX.ORG.RU

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

 , kolivas, patchset,


0

1

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

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

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

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

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

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

★★★★★

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

Ответ на: комментарий от Ab-1

>То нужно, то ненужно... Скажите мне будет в ядро приниматься всё что улучает работу десктопа? Или всё также будет линукс подстилкой для серверов?

Даешь KDE4 в ядре!!!

anonymous
()

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

и так ядро - монстр. всё нормально работает.

RedPossum ★★★★★
()

тут многие говнами на Коливаса исходят, хотя даже на опеннете была новость, что при сравнительном тестировании BFS и CFS, в последнем было больше отставание - 80%. После того как это заметили на примере BFS, сразу же исправили это отставание в CFS.

Так что и в мейнстриме от Коливаса есть толк.

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

>Я сейчас не занимаюсь делом, а треплюсь на каком то говно форуме, ну это просто ппц!

В этом конечно же виноват линукс и лично Линус Торвальдс.

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

> Да, есть у cfs проблемы при большом load average. Но это повод выяснить, почему же на этом железе такой LA? И эту проблему - решить.

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

cobold ★★★★★
()

Вот сейчас сижу смотрю кино. На часах бьет 00:00 и по крону запускается updatedb, который дико сканит винт. Я то понимаю что updatedb запустилось не потому что на часы посмотрел, а потому что кино превратилось в слайдшоу. НУ ДОКОЛЕ МНЕ ЭТУ СРАНЬ ТЕРПЕТЬ??!!! Только те орут что в Линукс на декстопе конфетка, кто от этого Линукса отгораживается безгуевыми серваками да аппаратными цисками. Неюзабельное неоптимизированно овно.

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

Странно, вообще-то я даже не замечаю не то что updatedb, а его совместно с trackerd и регулярным обновлением rss-читалки.

Небось чипсет от nvidia?

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

Интел раз

00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Intel Corporation Unknown device 4f4a
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 90
	I/O ports at 3438 [size=8]
	I/O ports at 345c [size=4]
	I/O ports at 3430 [size=8]
	I/O ports at 3458 [size=4]
	I/O ports at 3020 [size=32]
	Memory at 93226000 (32-bit, non-prefetchable) [size=2K]

Интел два

01:00.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
	Subsystem: Dell SAS 6/iR Integrated RAID Controller
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 169
	Region 0: I/O ports at ec00 [size=256]
	Region 1: Memory at fc4fc000 (64-bit, non-prefetchable) [size=16K]
	Region 3: Memory at fc4e0000 (64-bit, non-prefetchable) [size=64K]
	Expansion ROM at fc500000 [disabled] [size=1M]

все работает при самых жестких дисковых загрузках.

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

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

Забанили в google ?
crontab перестроить неосилил ?
Терпи тогда.

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

> freebsd-шного планировщика нет такой проблемы

Нет планировщика - нет проблемы

devl547 ★★★★★
()

Кстати, господа, а кто-нибудь собирал готовые пакеты для Ubuntu 9.10? Или на худой конец выкладывал в AUR?

Я бы воткнул вторым ядром на посмотреть, но собирать самостоятельно времени нет — внезапно наступила зима и заказчик забыл что в декабре новый год. Так что заморачиваться с пачсетами времени нет (

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

> Кстати, господа, а кто-нибудь собирал готовые пакеты для Ubuntu 9.10? Или на худой конец выкладывал в AUR?

В ауре давно есть kernel26-ck, но у него PKGBUILD какой-то черезжопный и в зависимостях пакеты из тестинга.

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

> Я то понимаю что updatedb запустилось не потому что на часы посмотрел, а потому что кино превратилось в слайдшоу.

И ты думаешь что в этом виноват именно планировщик процессов? Где хоть какие-то данные для диагностики проблемы, а не только брызганье слюной? Телепатить никому не интересно, хоть бы указал используемую версию дистрибутива/ядра, тип ФС, cpuinfo, список процессов и т.п.

Наверняка ведь используется раздел ext3 примонтированный в режиме data=ordered со всеми вытекающими последствиями при работе updatedb. И что там с i/o приоритетом процесса updatedb? Может он у тебя запускается с real time priority? :-О Честно говоря, другой причины тормозов при просмотре видео с одновременной работой updatedb я себе даже представить не могу. man ionice, короче включай мозги.

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

Не анонимуса ради, но как именно предлагаешь диагностировать подобные проблемы? Вот, например - при создании preallocated образа virtualbox вообще интерфейс подвисает.

Исходные данные
Железка: Q9650, 8GB, ICH8 контроллер SATA, 7200rpm винт.
Линукс: 2.6.32-zen, x86_64, bfs+bfq, aes-шифрование винта (dm-crypt/LUKS, без LVM)

Твои конкретные предложения?

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

> Да, раздел нативный ext4

Вообще сказки какие-то. Я на своей федорке, на шифрованном LVM под ext3 ничего такого не имею. Да, программы начинают загружаться медленнее, но никаких тормозов у уже запущенных (особенно, если диск они не кушают) нет.

Дай-ка попробую угадать... Диск сигейтовский?

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

Сигейтовский. А диск-то тут при чем? Почему в остальных осях ничего не тупит? (оффтопик, BSD)? Логично предположить, что дело в настройках. Железо - православнее некуда.

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

Сигейт как бы известен своими низкими результатами при многопоточной записи.

Да, и я бы начал с нормального дистрибутива, типа федоры или centsos. Лично меня смущает весь этот крэп:

2.6.32-zen, x86_64, bfs+bfq

2.6.27-31, cfs, cfq, включенный ahci в BIOS и подхваченные одноименным драйвером контроллеры. Вот тогда обсудим.

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

Собственно, с этого всего в поисках счастья я и ушел - было то же самое.
Поэтому и теряюсь в догадках. Независимо от дистра ведет себе одинаково на: Ubuntu, FC, Mandriva, Arch со стандартными вариантами и сборными ядрами.

Кстати, по поводу центоси (5.3) - она меня задрала своей нелюбовью флэшек и попыток слить на эти флэшки 20-30 гб, задрала именно тем, что почти сразу скорость падает до 200-300кб/с. Центось не на этой машине живет - на другой. С усб там все ок, ибо на винты льется со свистом. На флэшках были опробованы NTFS, FAT32, ext2, UDF.

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

Где-то явный косяк в железе, я бы начал ковыраться в BIOS. Через мои руки приличное количество железа прошло, нигде такого феерического говня я не видел. Тем более, не зависящего от версии ядра/дистрибутива.

annoynimous ★★★★★
()

Может не надо в ядро то, что «не обновлялся более 2-х лет», а сейчас вдруг «вышел из анестезии» и предложил?
Это даже не машина времени :)

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

Бегло погуглил. Были проблемы с IO-APIC. Загрузи с параметрами ядра noapic, nolapic и протести. Скорее всего, все ядра проца ты не увидишь, но интересно, пропадут ли тормоза на интенсивном I/O

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

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

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

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

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

А почему тогда трабл только в линуксах? Ну не бывает чудес. :(
Всегда так - какая-то неочевидная настройка в глубине сидит, про которую даже не думаешь.

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

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

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

Попробовал поставить zen-sources -> результаты на лице: 1. Все стало чуть чуть быстрее (на взгляд, на самом деле просто может как то плавней и быстрее только реагирует) наприер я смог запустить 4-ые vlc-шки без ни каких тормазов. На стандартном gentoo-sources 3-и уже тормозит. 2. Рекция юая, на порядок приятней откликается 3. Через ~ 10-ть минут вылитают Х ругаясь на dri

Вы говорите что руки кривые, почему же кривое ядро быстрее?

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

Я понимаю что у таких ребят как Линус нет времени на доработку ядра под Desktop системы. и по сему считаю, что те ребята которые по аналогии с zen ядром и скедулером Коливаса работают над улучшением юзабилити/скорости на десктопах становятся еще важнее, и если ядро официальное, или включеное для десктоп систем в дистрах не будет стоять по умолчанию линукс и десктоп ни когда не сойдутся в месте....

Меня например бесит когда во время копирования файлов мне приходится выключать тот же фильм по тому что смотреть его нереально.

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

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

Никто не говорит, что проблема простая. Но часто ее решение лежит совсем в иной плоскости, чем проявляется. Например, на вводе-выводе некорректно себя ведет контроллер прерываний. Что ты видишь? Видишь, как все «встает колом» при дисковой активности. А на самом деле система в это время встает на аппаратных прерываниях. И ладно бы обработчик тормозил в одном потоке, тогда бы на многопроцессорной тачке не тормозилось бы. Так ведь Линукс, обнаружив большое число несброшенных дисковых буферов создаст еще один поток VFS, занимающий еще одно ядро и так далее...

А проблема может быть банальной — кривое ACPI.

Попробуйте еще что-нибудь типа acpi=off

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

>У этого сета ограниченное применение. На NUMA системах работает плохо (да. У меня NUMA десктоп). Соответственно в мейнстрим этого не надо, ибо не устраивает всех. У кого то работает лучше чем cfq - ну вот и ладушки. Пользуйтесь. У меня, например, не работает. И не будет, что характерно, так как Коливас решает свои проблемы через упрощение, а cfq не зря сложный планировщик. И есть сомнения, что Коливас будет способен поддерживать свой код для работы на отличающихся от мейнстрима платформах. Где то читал, что для поддержки выбора разных планировщиков требуется серьёзно модифицировать большие куски стабильно работающего кода и огрести соответствующие последствия. Так что проблемы унылых нищебродов-маргиналов с древними или кривыми компами Линуса и компанию не волнуют. Патчи есть, пользуйтесь, а в ядро это недоразумение с проблесками гениальности не надо.

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

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

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

Мне кажется что Кон Коливас прав если не во многом, то отчасти, то что хороше для сервера может быть не приемлемо для десктопа, сервер например не расчитан что бы на нем крутили фильм и с флешки открывали документ, одновременно играя во что-то, и от него не требуется ТАКОЙ реакции юая, а тем более красивостей юая, но он это позволяет. Его задача распределить службы, важные для предоставления некого сервиса, пусть БД, или вэб, или и то и другое. На десктопе же важней как ОС общается с пользователем....

И боюсь людей которые пытаются перейти на Линукс частенько не устраивает эта проблема даже если закрыть глаза на отсутсвие внятных игр и некоторого софта.... (это хотябы вайном или виртуалками решить можно) И врядли из них хотябы 50% людей которые в сотоянии написать внятный отчет разработчикам или хотябы попробовать разные хаки и настройки ядра...

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

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

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

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

Не исключено, что патчи Коливаса не решают никаких проблем, а просто маскируют их наличие.

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

Не исключено, но так же можно утверждать обратное, но тут выходит безпочвенный разговор, нужно смотреть патчь, разбирать случай «помогло» и почему, и если этот патчь в чем то молодец, встраивать, нет указать создателю (патч то не единственны), что мол ничего он не делает - только ухутшает. а вот на тебе то что не ухудшает... И вот мол все смотрите в чем проблема ). Но получается подоругому:

- Ура, я сделал мега патчь - Уйди пративный все не так - А как же нужно - (Много технического мата, и ни какого внятного ответа)

/*за кадром что то толковое в патче - игнор. Ошибки патча - игнор. Запросы пользователей - игнор.*/

В результате, то что можно было исправить так и осталось, куча обыженых и ни как не проясненая ситуация. Ну вот хотя бы вы можете с увереностью 100% ну или хотябы 98% сказать что в патче нет ничего что нужно пользователем, и этот патчь только мешает решить важные проблемы? Я в этом не уверен, хотя и не берусь утверждать обратного....

А вот ребята из команды зен ядра что-то делают, и Колвис что-то делает... и мне кажется рано или поздно от этого будет толк, либо пересмотрят аналогичные части ядра либо как то пофиксят более глубокие дыры.... и т.д. А текущему пользователю приходится пока что молится на Колвиса и др. и отругиватся от тех кто их называет .... не буду цитировать ... а толком ни чем помочь не собных или не желающих ...

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

Так же само можно сидя на винде ругать майкрософт что мол они ....

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

>Странно, вообще-то я даже не замечаю не то что updatedb, а его

совместно с trackerd и регулярным обновлением rss-читалки.



Небось чипсет от nvidia?



0000:00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
0000:00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3)
0000:00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
0000:00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
0000:00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)
0000:00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
0000:00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3)
0000:00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)
0000:00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
0000:00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
0000:00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3)
0000:00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
0000:00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
0000:00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
0000:00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
0000:00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
0000:00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
0000:01:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
0000:18:00.0 VGA compatible controller: nVidia Corporation G71GL [Quadro FX 3500] (rev a1)
0000:2b:00.0 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
0000:2b:00.1 PCI bridge: NEC Corporation uPD720400 PCI Express - PCI/PCI-X Bridge (rev 06)
0001:40:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
0001:40:01.0 RAM memory: nVidia Corporation MCP55 LPC Bridge (rev a3)
0001:40:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3)
0001:40:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
0001:40:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3)
0001:45:00.0 RAID bus controller: 3ware Inc 9650SE SATA-II RAID PCIe (rev 01)


И тоже не замечаю тормозов при IO вообще.

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

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

Ну вот как ты смог из текста сделать совершенно противоположные смыслу текста выводы? Блондинка? Женская логика какая то.

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

> Сношаю себя за невнимательность. Описался.

Да ладно отмазываться-то!

Но там из контекста по моему понятно, что это описка.


Из контента лишь понятно что ты малолетний ламер, услышавший пару умных слов и решивший блеснуть своим «умишком».

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

>Из контента лишь понятно что ты малолетний ламер, услышавший пару умных слов и решивший блеснуть своим «умишком».

Чмоке, детка

anonymous
()
Ответ на: Ядро Линуса. от Camel

>«работа Линукса» или «работа ядра Линуса [Торвальдса]»

ядро работы Линуса Торвальдса

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