URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 69590
[ Назад ]

Исходное сообщение
"Патч, решающий проблемы с отзывчивостью Linux-десктопа"

Отправлено opennews , 06-Авг-10 11:30 
Для Linux-ядра представлен (http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ) небольшой патч (http://www.phoronix.com/forums/showpost.php?p=140694&postcou...), заметно повышающий отзывчивость работы интерфейса пользователя при выполнении системой активных дисковых операций. При копировании больших файлов у многих пользователей вызывает раздражение (https://bugzilla.kernel.org/show_bug.cgi?id=12309) ухудшение интерактивности выполнения операций в GNOME, KDE, Xfce и других графических окружениях (например, время реакции на действие пользователя в интерфейсе может достигать нескольких секунд).


URL: http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
Новость: https://www.opennet.ru/opennews/art.shtml?num=27537


Содержание

Сообщения в этом обсуждении
"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ххх , 06-Авг-10 11:31 
ну что, пусть добавляют в ванильное ядро... я думаю все только за будут.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено koblin , 06-Авг-10 11:33 
>ну что, пусть добавляют в ванильное ядро... я думаю все только за
>будут.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено vizor , 06-Авг-10 12:16 
Вообще говоря Линус очень хочет включить этот патч в ядро потому как он очень сильно оптимизирует некоторые моменты, но ребята занимающиеся VFS против, они хотят всё как следует протестить. Мол да может стать быстрее, но а если что-то отломается другое? Хотя Линус тоже прав - без попадания в одно из rc - этот патч не протестит потенциальное большинство людей

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено zlo.rt.mipt.ru , 06-Авг-10 12:52 
Ну, да. Linux не включал в ядро swap prefetch and bfs.
А почему тут вдруг захотел?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено dimqua , 06-Авг-10 14:04 
Его супер пупер десткоп на федоре вдруг затормозил :-D

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 06-Авг-10 14:42 
>Ну, да. Linux не включал в ядро swap prefetch

Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем. Тогда и проблемы с его латентностью не будут допекать :)



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено phaoost , 06-Авг-10 14:44 
причём здесь своп? дисковые операции это не только своп.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 06-Авг-10 15:07 
Ну, swap prefetch - это все-таки своп :)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 17:41 
а этот патч к swap prefetch как-то относится?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:43 
Вообще-то в сообщении выше была фраза:
> Ну, да. Linux не включал в ядро swap prefetch and bfs.

Которые не относятся к этому патчу, но относятся к латентностям.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 15:13 
> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.

Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 16:46 
например ?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ххх , 06-Авг-10 18:51 
>> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.
>
>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.
>

вы хотели сказать .Net'ом? А да, проги на дотнете, помимо прочего ещё и только под винду работают...


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено sHaggY_caT , 06-Авг-10 19:30 
>>> Как по мне - при современных объемах оперативы разумнее просто не юзать своп совсем.
>>
>>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.

Банк-клиенты (если речь только про десктоп), и большинство бизнес-систем из ряда CRM/ERP, если и про серверы


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 17:42 

>вы хотели сказать .Net'ом? А да, проги на дотнете, помимо прочего ещё
>и только под винду работают...

откройте для себя уже mono


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:44 
А лучше закройте и не открывайте. Тормозилки на чем-то полусовместимом с MS - а оно нам надо? :)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 08-Авг-10 04:54 
>А лучше закройте и не открывайте. Тормозилки на чем-то полусовместимом с MS
>- а оно нам надо? :)

не надо, и тем не менее работает не только в винде


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:41 
>Современные объемы оперативы нивелируются жавой, на которой, увы, еще написано кое-что нужное.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено zlo.rt.mipt.ru , 06-Авг-10 12:53 
>>ну что, пусть добавляют в ванильное ядро... я думаю все только за
>>будут.
>
>все да не все... основные разработчики ядра больше ориентируются на использоание linux
>на серверах и им плевать на латентность ядра на десктопах

Да. Это очень печально.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено anonymous , 06-Авг-10 14:16 
>латентность ядра на десктопах

Ты сам то хоть понял, что сказал?

http://ru.wikipedia.org/wiki/%D0%9B%D0%B...


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено koblin , 06-Авг-10 14:55 
Понял, латентность - задержка... А тебя что смущает?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено AdVv , 06-Авг-10 15:29 
>Понял, латентность - задержка... А тебя что смущает?

Вообще есть отличное русской слово "отзывчивость"



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено AdVv , 06-Авг-10 15:27 
>>латентность ядра на десктопах
>
>Ты сам то хоть понял, что сказал?
>
>http://ru.wikipedia.org/wiki/%D0%9B%D0%B...

В данном случае это русизм от Latency, а не то, что ты подумал.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Карбофос , 08-Авг-10 12:23 
просто достаточно добавить опцию в ядро: хотите - используйте. думается, на десктопный вариант вполне себя оправдывает.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено stranger , 06-Авг-10 11:49 
Это случайно не исправление ошибки с iowait?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 12:15 
похоже что с этим связано...

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 17:38 
У меня этой ошибки нет с чипсетом AMD. А с nvidia есть!!! Насколько я знаю, ошибка с iowait добавлена относительно недавно (год или 2 назад) и трудноуловима

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено John , 06-Авг-10 11:50 
Вот сама ошибка:
https://bugzilla.kernel.org/show_bug.cgi?id=12309
И да, народ тестировал этот патч - это пока не решение проблемы(к сожалению).

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ivan1986 , 06-Авг-10 12:18 
А судя по последним комментам - помогает

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено rfcr , 06-Авг-10 11:58 
Да, эта проблема существует.
Также как существует проблема зависания всего интерфейса при открытии сетевого ресурса (который например уже не доступен или до него плохой пинг)...

Т.е. получается странная какая-то многозадачность.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено letsmac , 06-Авг-10 12:50 
>Т.е. получается странная какая-то многозадачность.

Какая многозадачность если процессор во время копирования не работает ? В этом-то и проблема.



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено yopt , 06-Авг-10 12:52 
попробуйте включить DMA, ага

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено letsmac , 06-Авг-10 13:52 
>попробуйте включить DMA, ага

почитай про DMA ладно?  Он не снижает загрузку процессора - он его ВЫКЛЮЧАЕТ.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 20:20 
за слово "выключает" зачет. Похоже по DMA надо читать именно тебе.
А ничего что DMA уже не существует? И как таковой режим был только у ISA шины ?:) Если ты покажешь мне на PCI шине DMA контролер - я буду очень озадачаен.
И да у шин PCI и выше - похожий режим называется Bus mastering.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Andrey Mitrofanov , 06-Авг-10 14:06 
>Какая многозадачность если процессор

Процессор и контроллер DMA "реализуют" доступ к разделяемому ресурсу - памяти (это та, что буквой "M" работает в абревиатурах VM и DMA, да?). С букетом вытекающих отсюда локов, гонок, и проч.проблем синхронизации. К этому прибавляем всяческие трансляции адресов, о которых к.DMA знать не знает, но ядро _обязано учитывать, а также особенности и мис-фичи _множества очень различных _шин, чипсетов, мем-контроллеров, и пр., и пр. ...

...уже понятнее, откуда растут сложности и проблемы, и кто тут "школьник"?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 20:21 
>>Какая многозадачность если процессор
>
>Процессор и контроллер DMA "реализуют" доступ к разделяемому ресурсу - памяти (это
>та, что буквой "M" работает в абревиатурах VM и DMA, да?).
>С букетом вытекающих отсюда локов, гонок, и проч.проблем синхронизации. К этому
>прибавляем всяческие трансляции адресов, о которых к.DMA знать не знает, но
>ядро _обязано учитывать, а также особенности и мис-фичи _множества очень различных
>_шин, чипсетов, мем-контроллеров, и пр., и пр. ...
>
>...уже понятнее, откуда растут сложности и проблемы, и кто тут "школьник"?

А ничего что контролер DMA существует только на ISA шине?
А для остальных это Bus mastering - для которого доступ к памяти лиш один из режимов ?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:52 
>А ничего что контролер DMA существует только на ISA шине?

Это с фига ли? Под прямым доступом к памяти (Direct Memory Access, DMA) подразумевается любой доступ к памяти происходящий без участия основного процессора системы. Чисто по определению DMA как явления природы. То что какая-то там ISA и какой-то там контроллер на ней сдохли - мы рады. И что? А вас не смущает что DMA бывает например в ARMовских камнях, у которых вообще НИКОГДА не было никакой ISA шины как класса, равно как и контроллера на этой шине?

>А для остальных это Bus mastering

Bus mastering - это вполне конкретное понятие которым оперирует PCI. А ничего что DMA может существовать на очень разных шинах и механизмах? У какогонить ARM вообще PCI может и не быть. А вот DMA - быть. Нормально так? :)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 12:05 
Блин, два года мучился с этой проблемой на UbuntuStudio :(
и на планировщик cfq патч накладывал - не помагало, теперь вот этот патч пишут что не помагает... :(

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено letsmac , 06-Авг-10 12:16 
>>повышающий отзывчивость

Просто милашкой станет, добрым, отзывчивым :-)

>> время реакции на действие пользователя в интерфейсе может достигать нескольких секунд

В Windows аналогично. Кто-то решил перепаять DMA на что-то другое?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fedya , 06-Авг-10 12:25 
в 7-ке этой проблема решена. в линуксе эта фигня изначально. помню как еще на 2.4.x уже с VM  
от АА ( с RVR вообще пепец) запускал на 2 консолях make -j 10 в каталоге с исходниками КДЕ - так вот с третьей консоли войти в систему уже не получалось. это без Х-ов. в отличии от линукса на том же железе на соляре 8-й можно было в скрине запустить 10 (больше не пробовал) таких заданий и система оставалась отзывчивой. это был 2x PIII 2G мозгов.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено letsmac , 06-Авг-10 12:48 
Доработали до приличия стэк IRP вот и стало более-менее. Хотя CD всё равно мозг выносят? cкорость копирования упала, но что делать. В Mac OS X проблема вообще отсутствовала. Таки BSD.

>>это был 2x PIII 2G мозгов.

А причем тут процессор то ? Он в операциях DMA как-бы не участвует.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fedya , 06-Авг-10 13:01 
проблемы в VM причем тут DMA? на одинаковом железе с одинаковым DMA соляра работала нормально, линукс имел проблемы. а железо описано просто для информации. для информации: использую линукс и винду, соляру не использую. т.е. суждение не предвзято.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено letsmac , 06-Авг-10 13:50 
>соляра работала нормально, линукс имел проблемы.

Реализация логики работы с контроллером DMA в защищенном режиме - это вообще-то нетривиальная задача. Вы вообще понимаете как работает DMA?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 20:23 
>>соляра работала нормально, линукс имел проблемы.
>
>Реализация логики работы с контроллером DMA в защищенном режиме - это вообще-то
>нетривиальная задача. Вы вообще понимаете как работает DMA?

где вы нашли антиквариат с DMA контролером в наше время ?:)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:54 
>в 7-ке этой проблема решена.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 12:28 
А кто может подробно объяснить как наложить этот патч на Debian?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 12:43 
>А кто может подробно объяснить как наложить этот патч на Debian?

этот патч накладывают на исходники ядра, а не на дистрибутив...


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ононим , 06-Авг-10 13:35 
что за никчемный ответ. иногда лучше промолчать, чем постить пустые коменты.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 14:41 
Ответ абсолютно точный, но совершенно бесполезный.
Как водится.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ононим , 06-Авг-10 13:37 
>А кто может подробно объяснить как наложить этот патч на Debian?

как-то так:

Cross your fingers,.

sudo apt-get build-dep linux-source
sudo apt-get install linux-source make-kpkg
cd /usr/src
sudo tar vxf linux-source-2.6.32.tar.bz2
ln -s linux-source-2.6.32 linux
cd linux
cp /boot/config-2.6.32-21-generic ./.config

Not sure where to get the patches in a file so you can just wget but
next just...

wherever you find the patch files just
patch -p0 < whereverthepatchwas.txt

sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers

you'll find your deb's in the /usr/src

or just
https://help.ubuntu.com/community/Kernel/Compile

думаю, осилишь перевести.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено XoRe , 06-Авг-10 13:48 
>[оверквотинг удален]
>patch -p0 < whereverthepatchwas.txt
>
>sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers
>
>you'll find your deb's in the /usr/src
>
>or just
>https://help.ubuntu.com/community/Kernel/Compile
>
>думаю, осилишь перевести.

Вау, клево!
Про дебиан понял.
А на убунту как наложить?)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Andrey Mitrofanov , 06-Авг-10 13:53 
>>patch -p0 < whereverthepatchwas.txt
>Вау, клево!
>Про дебиан понял.
>А на убунту как наложить?)

Кляньчить по форумам ссылку на PPA.)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено proDOOMman , 06-Авг-10 15:27 
Клянчу. Дайте ссылочку на PPA, плиз =)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 17:39 
>Клянчу. Дайте ссылочку на PPA, плиз =)

Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь. Заодно патч для второго старкрафта наложи.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено proDOOMman , 06-Авг-10 18:07 
>>Клянчу. Дайте ссылочку на PPA, плиз =)
>Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь.

Зачем по такой жаре лишний раз нагружать проц? Пусть лучше ланчпадовские сервера греются
>Заодно патч для второго старкрафта наложи.

???


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 21:07 
Ага. PPA с ядром и патчем для StarCraft, ядро и патч для улучшенной производителоьности сервера, ядро и патч для производительности настольной системы, ядро с какими-нибудь двумя патчами, новое ядро с двумя патчами, ядро с набором патчей от Коливаса... Вам какое? "Яблоко!" "Тьфу! То есть ам." "Мытое яблоко" "А то что, не мытое было?" "Не мытое!" "Тогда то тьфу, а это ам" "Яблоко мытое водой" "Погоди, а то яблоко чем тогда мыто было?" "Ну уж точно не водой!".
О какой нагрузке идёт речь? Вам жалко 20-ти минут на слабом компьютере? Лучше подготовить исходник, залить его на Launchpad, в случае ошибки ещё раз, потом скачтаь пакет и установить?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено proDOOMman , 06-Авг-10 21:45 
>Ага. PPA с ядром и патчем для StarCraft, ядро и патч для
>улучшенной производителоьности сервера, ядро и патч для производительности настольной системы, ядро
>с какими-нибудь двумя патчами, новое ядро с двумя патчами, ядро с
>набором патчей от Коливаса... Вам какое? "Яблоко!" "Тьфу! То есть ам."
>"Мытое яблоко" "А то что, не мытое было?" "Не мытое!" "Тогда
>то тьфу, а это ам" "Яблоко мытое водой" "Погоди, а то
>яблоко чем тогда мыто было?" "Ну уж точно не водой!".
>О какой нагрузке идёт речь? Вам жалко 20-ти минут на слабом компьютере?
>Лучше подготовить исходник, залить его на Launchpad, в случае ошибки ещё
>раз, потом скачтаь пакет и установить?

Успокойтесь и выдохните. А потом идите и играйте в свой старкрафт


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Zenitur , 07-Авг-10 02:09 
Одна из самых популярных игр на планете. Почему вам не нравится именно эта часть моего сообщения?
Насчёт "выдохните" - классику надо знать: http://www.youtube.com/watch?v=Gsh3MTLqrkQ

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:59 
>Идиотизм. Берёшь и патчишь, проприетарные драйверы затем переустанавливаешь.

Ага, тут +36 за бортом. И дым коромыслом как бонус. Для полноты картины надо еще +100 ватт тепла перед своим носом выдуть, да? Спасибочки, конечно, но пускай другие воздух погреют лучше :). Кстати, у меня кажется нет проприетарных дров в системе. То-есть, мне же меньше геморроя :)

>Заодно патч для второго старкрафта наложи.

Нафиг-нафиг. Как минимум - пусть сперва сделают версию под линух.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 05:20 
# patch -p1 < vmscan.patch

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено zlo.rt.mipt.ru , 06-Авг-10 12:47 
А куда Вы, товарищи, дели BFQ, BFS?
Они не решают проблемы с отзывчивостью?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено redixin , 06-Авг-10 13:45 
нет

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено zlo.rt.mipt.ru , 07-Авг-10 12:07 
Вы, право же, шутите. Посмотрите что такое BFQ.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iZEN , 06-Авг-10 13:08 
User294>А кто безгрешен? Или какойнить линуксулятор - это типа не костыль?

Ещё вспомни о WINE. Ага.

Кстати, на линуксуляторе баг 12309 мне не удалось воспроизвести. Может подскажешь, что нужно сделать? ;)

User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?

Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ононим , 06-Авг-10 13:32 
кто знает, когда на опеннете появится функция игнора всяких умников?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено blackjack , 06-Авг-10 13:41 
Уж лучше так чем карма/инвайты и т.д.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 13:55 
Есть функция "не читать комменты" - все равно они все такие (и этот тоже)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 06-Авг-10 14:54 
> (и этот тоже)

Рекурсия :P


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Andrey Mitrofanov , 06-Авг-10 13:56 
>кто знает, когда на опеннете появится функция игнора всяких умников?

Лучше "скрывать _новости и посты в форуме из -другого лагеря-" + деленгие на лагеря: win, lin, bsd, minix, beos, ...... Правда, не понятно, чего делать с взрыв-смесями типа lin+bsd прямо в новости.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено northbear , 06-Авг-10 19:38 
Запрещать, как вызывающие межконфессиональную рознь...

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 13:48 
> межконфессиональную

Приравняем *NIXоидство к религии?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 18:00 
>Запрещать, как вызывающие межконфессиональную рознь...

Ага, и вообще, лучше оставить какую-нибудь одну систему как расово верную. Правда, чем это потом будет отличаться от MSDN какого-нить?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 13:59 
>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!

ext4 - эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в снапшотах и умеет журналирование на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная фряшная UFS2? НИЧЕГО!


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено z , 06-Авг-10 14:06 
>ext4 - эта "пачка костылей и подпорок" обеспечивает продакшен

что весьма печально


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 06-Авг-10 14:53 
>Ещё вспомни о WINE. Ага.

Толсто. У меня вообще никакого вине нету например. Он мне не нужен.

>Кстати, на линуксуляторе баг 12309 мне не удалось воспроизвести. Может подскажешь, что нужно сделать? ;)

Пропатчить линукслятор, что же еще? :)

>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>Эта "пачка костылей и подпорок" обеспечивает продакшен,

Как-то редко оно в продакшне то встречается. EXTы явно чаще.

>не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС.

А фигли толку, если дизайн ископаемый?

> А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!

Во первых, это умеют другие слои. Во вторых - какая она нафиг суперсовременная? Это шутка такая? Это ж EXT3 на стероидах. Вот только бздуны костылили по принципу "выкрасить и выбросить", навернув много вычурных, красивых и правильных костылей к древней и тупорылой ФС. Не меняющих принципиально свойства ФС, только исправляющие наиболее кондовые грабли в виде "fsck хреначит часами". Получилось академически стройно и нахрен не впившееся на практике. Линуксоиды пролечили журналинг чуть ли не десятилетие назад и потому в этот раз костылили ископаемое исключительно в направлении подъема его скорострельности. Что как раз всем и было надо в основном. В итоге - их старикан с новыми ногами^W^W экстентами - бегает как спортсмен, хоть и не являлся таковым изначально и был нехило перекроен. А некоторые другие не осилили капитально перекроить свою ФС, хотя-бы поюзав экстенты. Если что - экстенты в многих случаях ведут себя намного лучше чем блоки по скорости работы ФС. Именно поэтому их и втыкают в все современные дизайны ФС. Посмотрите на ФС разрабатываемые в последнее время. Все как на подбор юзают экстенты. Ну уж наверное не потому что они дураки, правда? :)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iZEN , 06-Авг-10 16:58 
>Как-то редко оно в продакшне то встречается. EXTы явно чаще.

Вот-вот. EXT'ы (-2, -3, и -4) — это подпорки и костыли древней как говно мамонта EXT1 начала 1990-х — встречаются куда чаще отрихтованной и доведённой до ума стандартной юниксовой ФС в 2005 году UFS2.

>>не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС.
>
>А фигли толку, если дизайн ископаемый?
>
>> А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
>
>Во первых, это умеют другие слои.

Во-первых, эта отговорка уже не катит. Пока ты склеиваешь необходимые слои между собой и получаешь рабочий снапшот, может пройти очень много времени, что непозволительно для продакшена. К тому же, снапшоты линуксовых ФС нужно делать на неживой-отмонтированной ФС. И, да, скорость записи на раздел со снапшотом в линуксе почему-то проваливается в разы по сравнению с разделом без снапшота. Почему так? Ведь другие нормальные ФС, поддерживающие снимки внутри себя, не страдают от этого дефекта.

>Ext4
>Во вторых - какая она нафиг суперсовременная? Это шутка такая? Это ж EXT3 на стероидах.

Вроде и нет больше _современных_универсальных_ ФС в Linux, годных к продакшену. Или я не прав?

>Вот только бздуны костылили по принципу "выкрасить и выбросить", навернув много вычурных, красивых и правильных костылей к древней и тупорылой ФС. Не меняющих принципиально свойства ФС, только исправляющие наиболее кондовые грабли в виде "fsck хреначит часами". Получилось академически стройно и нахрен не впившееся на практике.

Устойчивую к сбоям UFS2, не нуждающуюся для защиты метаданных в журнале ты назвал "кондовыми граблями". Ну-ну. Посмотрел бы я на надёжность современных линуксовых ФС, если ВНЕЗАПНО выключить электричество, а у них не окажется журнала.

>Линуксоиды пролечили журналинг чуть ли не десятилетие назад и потому в этот
>раз костылили ископаемое исключительно в направлении подъема его скорострельности.

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

>Что как раз всем и было надо в основном. В итоге - их
>старикан с новыми ногами^W^W экстентами - бегает как спортсмен, хоть и
>не являлся таковым изначально и был нехило перекроен. А некоторые другие
>не осилили капитально перекроить свою ФС, хотя-бы поюзав экстенты. Если что
>- экстенты в многих случаях ведут себя намного лучше чем блоки
>по скорости работы ФС. Именно поэтому их и втыкают в все
>современные дизайны ФС. Посмотрите на ФС разрабатываемые в последнее время. Все
>как на подбор юзают экстенты. Ну уж наверное не потому что
>они дураки, правда? :)

Правда. Потому что экстенты на больших объёмах обслуживаемых данных эффективнее простых битовых карт (сканирование и определение непрерывных цепочек блоков тупо быстрее идёт). Но только на больших объёмах.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено sHaggY_caT , 06-Авг-10 19:41 
>Во-первых, эта отговорка уже не катит. Пока ты склеиваешь необходимые слои между
>собой и получаешь рабочий снапшот, может пройти очень много времени, что
>непозволительно для продакшена.

Чаще всего, занимает менее секунды. В чем проблема сделать lock в той же базе данных(при этом доступ на чтение сохранится!), или приостановить, без отказа в обслуживании, виртуалку/контейнер?

> К тому же, снапшоты линуксовых ФС нужно делать
>на неживой-отмонтированной ФС.

Глупость, нет такого, Вы что-то перепутали!


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 19:55 
самое интересное, что это ему уже тысячу раз писали.
поэтому... ну дайте человеку высказаться. толку то никакого.

>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!

интересно, а вот это https://www.opennet.ru/base/sys/softupdates_idea.txt.html айзен читал?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iZEN , 07-Авг-10 00:28 
>самое интересное, что это ему уже тысячу раз писали.
>поэтому... ну дайте человеку высказаться. толку то никакого.
>
>>User294>А может, про UFS с пачкой костылей и подпорок вы уже забыли?
>>>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании и умеет делать снапшоты на живой (подмонтированной в RW) ФС. А что умеет из этого делать суперсовременная линуксовая Ext4? НИЧЕГО!
>
>интересно, а вот это https://www.opennet.ru/base/sys/softupdates_idea.txt.html айзен читал?

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



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 07-Авг-10 03:49 
угу. я так и понял, что это не недоговорённость, а рассчёт на то, что тут все уже научились читать мысли айзена. ну или на худой конец читают между строк:
>Эта "пачка костылей и подпорок" обеспечивает продакшен, не нуждатся в журналировании

.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 18:14 
>Конечно. Поэтому я говорю о целостности структур метаданных файловой системы, а не
>данных пользователя.

Ну и чем оно принципиально лучше журнала в EXT3 и 4 тогда? Такие допущения и он тоже обеспечивает. Только EXT3 еще и существовал мноооооого лет ;).



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 08-Авг-10 14:03 
интересно другое - когда rc ext4 файлы кед херил, работая в таком же режиме как sf, его айзены хаяли по чём зря. а во фре это уже не баг, а супер фича.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iZEN , 07-Авг-10 00:36 
>> К тому же, снапшоты линуксовых ФС нужно делать
>>на неживой-отмонтированной ФС.
>
>Глупость, нет такого, Вы что-то перепутали!

Признаю, что-то перепутал. Высказывание касалось только XFS, которую нужно "замораживать" перед снимком. Тем не менее:
http://maximum-value.blogspot.com/2009/01/lvm2.html
"LVM2 и снапшоты

Мало где говорится о том, что при использовании снапшота в LVM используется неразмеченное пространство в данном томе (Volume), хотя это совсем не очевидно. Т.е. имея 1Gb неразмеченного пространства мы можем сделать снапшот размером до 1G (т.е. и -L1G), но что будет, если мы при этом сделаем снапшот размером 2G и дождёмся, пока он заполнится больше чем на 1Gb?

UPD: снапшот можно сделать размером не более чем неразмеченное пространство в томе, иначе получим "Insufficient free extents"."
— такого маразма нет в UFS2.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 05:39 
>такого маразма нет в UFS2.

Интересно, куда девается снапшот, если на диске остался 1Mb и не размеченая в 1Gb?
А ты попросил создать 2G снапшот? Может поверх данных писать начнёт?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 08-Авг-10 05:31 
>>такого маразма нет в UFS2.
>
>Интересно, куда девается снапшот, если на диске остался 1Mb и не размеченая
>в 1Gb?
>А ты попросил создать 2G снапшот? Может поверх данных писать начнёт?

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 08-Авг-10 07:59 
один хрен при нехватке места снепшота не будет.
просто тут процесс контролируется, а у вас нет.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 08-Авг-10 14:26 
>и не нужно говорить какого объема создавать снапшот - удивитесь.

Удивляюсь :)  
BSD создали для того, чтоб человек думал, а не машина...
эх, где мои счётные палочки с гидроподъёмником.    


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено sHaggY_caT , 07-Авг-10 18:19 

>Высказывание касалось только XFS, которую нужно "замораживать" перед снимком.

Уже не нужно


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 07-Авг-10 17:39 
>как говно мамонта EXT1 начала 1990-х

Все так. Только к EXT4 старикана так перепилили что оригинал и не узнать. Тут вам и экстенты, и хешированные директории, и отложенное выделение. В общем все как у большинства иных подобных ФС типа XFS, JFS, etc. Не свежак и не последний писк, но и параметры не позорные. Весьма резвая такая ФС. И отлаженная временем.

> — встречаются куда чаще

Угадаете с трех раз почему? Наверное секрет в том что с хешированными дирами и экстентами - параметры EXT4 даже похожи на что-то приличное.

>отрихтованной и доведённой до ума стандартной юниксовой ФС в 2005 году UFS2.

Что-то никому этот ваш UFS2 как файловая система толком не нужен. Может быть, это потому что дисковые структуры недалеко ушли от "говна мамонта", со всеми вытекающими, как то неважненькая производительность на ряде нагрузок?

>>Во первых, это умеют другие слои.
>Во-первых, эта отговорка уже не катит.

Это зависит от того шашечки или ехать. Если цель разрулить задачу - это одно. Если подрочить на академически правильное решение - другое.

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

А мужики то не знают. Странно. Наверное iZEN им не попадался. Упущеньице.

>К тому же, снапшоты линуксовых ФС нужно делать на неживой-отмонтированной ФС.

Откуда это следует?

>И, да, скорость записи на раздел со снапшотом в линуксе почему-то проваливается
>в разы по сравнению с разделом без снапшота. Почему так?

Вам анонимаус объяснял вроде? Это было безрезультатно? При том он объяснял что однозначно выигрышной стратегии нет, IIRC.

>Ведь другие нормальные ФС, поддерживающие снимки внутри себя, не страдают от этого дефекта.

Да, конечно, btrfs какойнить так работает что снимки - просто его логика работы. Это впрочем не означает что у него других проблем не будет.

>Вроде и нет больше _современных_универсальных_ ФС в Linux, годных к продакшену. Или
>я не прав?

XFS тот же - он может и не суперуниверсал, но на ряде применений (большие файлы, etc) очень так ничего. И на несколько дисков размазывается хорошо, чем ext4 похвастать не может.

>Устойчивую к сбоям UFS2, не нуждающуюся для защиты метаданных в журнале ты
>назвал "кондовыми граблями".

Про ее устойчивость к сбоям вам имхо доступно рассказали в соседнем посте. Вот у настоящих CoW файловых систем с недеструктивной записью - там да, устойчивость к сбоям есть. На уровне устройства ФС, так что и файлы и метаданные можно вернуть к какому-то предсказуемому состоянию, исключив ситуации "запись обломалась на середине - файл наполовину перезаписан".

>Ну-ну. Посмотрел бы я на надёжность современных линуксовых ФС, если ВНЕЗАПНО
>выключить электричество, а у них не окажется журнала.

И даже с журналом - гарантируется непротиворечивое состояние журнала и структур ФС. А вот что будет с файлами - вопрос номер два. Гарантию атомарности записи данных + метаданных в классических ФС дает полное журналирование. А оно тормозное из-за двойной операции записи.

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

Если журналятся только метаданные - то не отнимает. Обычно все соглашаются на такой вот компромисс. В итоге тормоза могут возникать только при metadata-intensive workload'ах. А это довольно нишевые и не частые случаи (именно поэтому кстати вырубить всякие там времена доступа - отличная идея).

>так и центрального процессора. Лучше отказаться от журнала вообще и обеспечить механизм
>внутренней согласованности жизненно важных структур,

Насколько я понял спич по любезно приведенной в соседнем сообщении ссылке - механизм soft-updates в UFS2 не обещает что если я записывал файл и если все фигакнулось в момент записи то у меня будет или старый файл, или новый. А не нечто, наполовину старое и наполовину новое, не факт что юзабельное вообще.

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

Строго говоря - я не без причин полагаю что будущее за ФС с недеструктивной записью, т.е. CoW-подобными файловыми системами. У них конечно своих грабель навалом, однако их плюсы в виде недеструктивности и возможности хранить более 1 версии файла - явно перевешивают.

>>Ну уж наверное не потому что они дураки, правда? :)
>Правда. Потому что экстенты на больших объёмах обслуживаемых данных эффективнее
>простых битовых карт (сканирование и определение непрерывных цепочек блоков
>тупо быстрее идёт). Но только на больших объёмах.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iZEN , 08-Авг-10 22:54 
>>как говно мамонта EXT1 начала 1990-х
>
>Все так. Только к EXT4 старикана так перепилили что оригинал и не
>узнать.

Ага. Аж оторопь порой берёт: http://www.linux.org.ru/forum/general/5205490
"ext4 не видит суперблока после сбоя питания

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

после включения в GRUBе выбрал тот самый сбойнувший Debian, а он не смог найти раздел. стоит также Mandriva, в нее и загрузился. слил убитый рутовый раздел dd-шкой в образ, благо он всего 40 гиг. и стал пытаться гуглить и восстановить. fsck.ext4 -y /dev/sdd1 лечил около часа, в итоге все в лост+фаунд с непотребными именами.

залил обратно из образа. при запуске так же предлагает чистить и чинить. тут с отказной опцией: [root@sg mnt]# fsck.ext4 -n /dev/sdd1 e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Superblock invalid, trying backup blocks... Superblock has an invalid journal (inode 8). Clear? no fsck.ext4: Illegal inode number while checking ext3 journal for /dev/sdd1

если подсунуть другой суперблок: [root@sg mnt]# fsck.ext4 -nb 8193 /dev/sdd1 e2fsck 1.41.4 (27-Jan-2009) fsck.ext4: Bad magic number in super-block while trying to open /dev/sdd1 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 <device>

также пробовал подставлять 8193, 24577, 40961, 57345, 73729, взятые из статьи: http://breys.ru/blog/297.html - результат тот же.

при этом fdisk все видит правильно: [root@sg mnt]# fdisk -l /dev/sdd Диск /dev/sdd: 1000.2 ГБ, 1000203804160 байт 255 heads, 63 sectors/track, 121601 cylinders Units = цилиндры of 16065 * 512 = 8225280 bytes Disk identifier: 0x37abde1d Устр-во Загр Начало Конец Блоки Id Система /dev/sdd1 1 4864 39070048+ 83 Linux /dev/sdd2 4865 121601 937689952+ 5 Расширенный /dev/sdd5 4865 121601 937689921 83 Linux

а gparted не опознает файловую систему на том разделе.

зы. модераторам. перед написанием сообщения на форум предлагаете читать FAQ - ссылка мертвая (404).
sunny178 (08.08.2010 21:30:58) "

Весело у вас. :)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 10-Авг-10 00:47 
>Ага. Аж оторопь порой берёт: http://www.linux.org.ru/forum/general/5205490
>"ext4 не видит суперблока после сбоя питания

Ага, только вот...
1) Не указан кернел. Кернелы до .30 ... .32 с EXT4 вообще будет юзать только мазохист.
2) У чувака довольно старая версия ext2 утилсов. У меня вот например e2fsck 1.41.11 на десктопе в кубунте.
3) Там маловато информации о том что за ФС, какие фичи юзались, какая конфигурация системы, что произошло, кто и насколько виноват и прочая. Например "а gparted не опознает файловую систему на том разделе" наводит на разные мысли. Могла допустим таблица разделов попортиться и все смещения съехали. Если сунуться 5 раз в неверные данные - разумеется суперблок там будет "порушен". А человек глазами то смотрел - а есть ли суперблок в том месте в котором он ищет вообще? А то может там вообще были не суперблоки? :)
4) Если тщательно прикапываться - ну нате вам в вашем же духе, например http://lists.freebsd.org/pipermail/freebsd-fs/2008-February/... Наверняка еще что-то такое нагуглится запросто (но меньше чем EXT4 - сколько его юзает народа, а сколько UFS2?). Или вы как наивный чукотский юноша думали что качественно убить при сомнительных обстоятельствах можно только EXT4? Да хрен там, практически что угодно можно уложить при правильном подходе к делу. А EXTовские утили к слову одни из наиболее настырных. Они пытаются что-то отскрести даже там где чекалки других ФС сдаются. EXT4 в этом плане доверия поменьше чем EXT3, в силу новизны структур. Однако по информации как тут - даже не понятно кто виноват и багу например не напишешь.

[skip]
Не обязательно сюда все сообщение цитировать, имхо - читатели явно могут по ссылке пройти.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено dimqua , 06-Авг-10 14:08 
Ждём в zen-kernel.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено umbr , 06-Авг-10 14:15 
Кажеться, дело движется к разделению ядра на сервер/десктоп форки.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Andrey Mitrofanov , 06-Авг-10 14:20 
Сразу, как только Линус почкованием разделится, ага.....

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено User294 , 06-Авг-10 15:06 
>Кажеться, дело движется к разделению ядра на сервер/десктоп форки.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Живот , 10-Авг-10 13:07 
Это еще зачем? Одно будет, если же конфиг.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Живот , 10-Авг-10 13:08 
>Это еще зачем? Одно будет, если же конфиг.

*есть


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено доброжелатель , 06-Авг-10 14:41 
И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объясните
sudo apt-get build-dep linux-source
sudo apt-get install linux-source make-kpkg
cd /usr/src
sudo tar vxf linux-source-2.6.32.tar.bz2
ln -s linux-source-2.6.32 linux
cd linux
cp /boot/config-2.6.32-21-generic ./.config
Not sure where to get the patches in a file so you can just wget but
next just...
wherever you find the patch files just
patch -p0 < whereverthepatchwas.txt
sudo make-kpkg --initrd --append-to-version=-custom kernel-image kernel-headers

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Мимо проходил , 06-Авг-10 14:52 
Патч установился на 2.6.32? :)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Capth , 06-Авг-10 14:57 
>Патч установился на 2.6.32? :)

Суровая девушка на ресепшене попалась)



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Knuckles , 06-Авг-10 15:01 
Бедняжка.
Вот с этим парнем вы одинаково мыслите, видимо.
http://www.bannedinhollywood.com/wp-content/uploads/2010/05/...

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено koblin , 06-Авг-10 15:32 
> И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объясните

и эти люди агитируют нас за Windows. Вы тетеньке-бухгалтеру обьяснити как устанавливать SQL сервер и 1С и как в нем запрограммировать форму или отчет или как установить и настроить клиент-банк! Да они сами даже принтер или мышь не подключат к компьютеру!


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено тру , 06-Авг-10 16:11 
SQL сервер и 1С в итоге работают, а сабжевый костыль - как обычно
https://www.opennet.ru/openforum/vsluhforumID3/69590.html#6
https://www.opennet.ru/openforum/vsluhforumID3/69590.html#69


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 19:40 
ну и чего тогда так волнуешься? оно тебе нужно? или ты таким образом волонтёром винды работаешь?
мне вот не нужно. хоть линух полностью вытеснил винду уж лет как 5 на моих десктопах. мне другие, волее важные моменты интересны.

зы:
ща народ может расскажет, как бысто вызвать диспетчер задач в загруженной винде?
а то порой такая "отзывчивость" наступает, что несколько минут составляет.
правда когда диспетчер всё-таки открывается, то загрузка уже ниже 30% и что грузило его так долго остается тайной.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 11:58 
Тогда, быть может, его имеет смысл держать свернутым на фоне?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 07-Авг-10 12:15 
>имеет смысл держать свернутым на фоне?

пара занимаемых метров погоды не делают, это вам не тормознутый gnome system monitor


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 07-Авг-10 19:26 
бесполезно. не помогает.
по всему видно, что он просто ждёт освобождения неких ресурсов.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено JL2001 , 08-Авг-10 14:14 
>бесполезно. не помогает.
>по всему видно, что он просто ждёт освобождения неких ресурсов.

подтверждаю, много много раз на 2k3


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено yurik81 , 06-Авг-10 16:28 
>И эти люди агитируют за линукс на десктопах, со всеми его детскими болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов. Вы девочке на ресепшне вот это всё объясните

Вы и есть та девочка на ресепшне?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено alf , 06-Авг-10 17:15 
>чтобы перестал виснуть при копировании файлов.

Ядро 2.6.33.5, не виснет, брат жив.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Blayder , 06-Авг-10 19:27 
У девушки на ресепшене для этого есть тех саппорт в компании или на крайняк фирма, облуживающая их компанию, не? Или вы думаете на винде она тоже сама чистит всякие темпы, гоняет вирусню, инсталлит принтеры и т.д. и т.п.?

Хватит уже этим маразмом болеть про домохозяек и блондинок.
Большая часть юзверей венды даж не знаю как антивирь запустить на скан системы.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 19:44 
не. у них девушки на ресепшене сами ставят винды, сами гоняют вирусы, сами фильтруют/рассылают спам.
а они, айтишнеГи, только ходят, надувают щеки, дышат перегаром.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 06-Авг-10 20:02 
Ага, а ещё они предлагали школьникам самостоятельно обслуживать свой школьный линапс. И каждый блин школьник вместо прогулок на свежем воздухе будет сидеть в душной аудитории и накладывать патч за патчем, пытаясь привести глючную ось в рабочее состояние.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 07-Авг-10 05:49 
не патчи, а апдэйты. боюсь на винды патчи не выпускаются.
впрочем как и на бинарные дистры.
да не видел я ни разу чтоб играли в wow на свежем воздухе.
короче, популистский, тупой тролинг.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 21:10 
>И эти люди агитируют за линукс на десктопах, со всеми его детскими
>болезнями вроде компиляции в консоли, чтобы перестал виснуть при копировании файлов.
>Вы девочке на ресепшне вот это всё объясните

Здесь сайт для любитлей и профессионалов.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 15:49 
Патч не решает проблему. Совсем.

Убунта 10.04, ваниль + патч.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ACCA , 06-Авг-10 21:21 
>Патч не решает проблему. Совсем.
>
>Убунта 10.04, ваниль + патч.

Убунта 10.04 искаропки. Древний Dell Dimension 9100 = Pentium D + SATA. Ядро 2.6.32-24-generic когда-то приползло с апдейтом, никаких патчей.

Проблема c dd напрочь отсутствует.

Пробовал pipes and processes от Томаса Пиларски - заметно подтормаживает, что неудивительно при 104 активных процессах, latency не больше 0.2 сек.

min:0.012ms|avg:0.012-0.013ms|mid:0.013ms|max:195.542ms|duration:69.787s


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 16:41 
Както недавно писал образ двд на 8 гиг. 3,5 часа!!! И при этом системной не возможно было пользоваться. 12309 такая 12309 :(

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено linux_must_die , 06-Авг-10 16:59 
баг с iowait исправят когда redhat свистнет - инфа 100%
те как обычно, лет через пять. а пока добавляются драйвера 1001 левого железа,ведется борьба с нарушителями gpl и форкается 1001 дистрибутив.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 06-Авг-10 17:09 
У Торвальдса баг на федоре не проявляется. Т.о. статус бага сейчас поменяется на WORKSFORME
https://bugzilla.kernel.org/page.cgi?id=fields.html#status

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 17:24 
>У Торвальдса баг на федоре не проявляется. Т.о. статус бага сейчас поменяется
>на WORKSFORME
>https://bugzilla.kernel.org/page.cgi?id=fields.html#status

сомневаюсь что им удается держать Торвальдса в неведении... ;)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Ъ , 07-Авг-10 09:04 
Не это главное. Разрушен внутренний мир многих людей считавших, что Linux самая лучшая ОС на планете, вот что печально. Это же миллионы покалеченных судеб!

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено анонимиус , 06-Авг-10 17:18 
Это из другой песни.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено йло , 06-Авг-10 17:47 
проблема исчезает, если монтировать ФС с опцией sync

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 20:16 
>проблема исчезает, если монтировать ФС с опцией sync

:) Тормозить так уж всем сразу?

можно ещё  atime, diratime, barrier (где есть), norelatime, wsync (XFS), align


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено filosofem , 06-Авг-10 18:47 
А есть кто-нибудь, у кого эта бага не проявляется. Я вообще не понимаю о чем разговор. Ни разу не видел, чтобы на недревнем железе были тормоза из-за копирования. Объясните как репродуцировать проблему, какая файловая система должна быть, какое ядро, видяха, видеодрайвер, версия иксов, какой SATA(PATA) контроллер используется, какой чипсет в конце концов? Если это про ntfs-3g  и iowait, то не интересно.
А то так написано, как будто это повсеместное явления, а у меня ни на одном компе не наблюдается, я уже 10 dd запустил и в наутилусе копировал в несколько потоков и болванку нарезал одновременно и нормально десктоп работает.
Правда иксы пропатченные, может быть в этом дело?

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено копираст , 06-Авг-10 18:56 
>А есть кто-нибудь, у кого эта бага не проявляется

iZEN

>Объясните как репродуцировать проблему

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено edo , 06-Авг-10 21:04 
>на лоре есть тред

url?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Кракен , 06-Авг-10 21:15 
судь в
dd if=/dev/zero of=/some/file bs=8M
С параметрами дд можно поиграть. Заметишь сразу, если у тебя оно есть, т.е. люди даже ctrl+c не могут иногда нажать из-за диких тормозов, или ждут пока команда сработает секунт 10-30.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено edo , 06-Авг-10 21:20 
>судь в
>dd if=/dev/zero of=/some/file bs=8M
>С параметрами дд можно поиграть. Заметишь сразу, если у тебя оно есть,
>т.е. люди даже ctrl+c не могут иногда нажать из-за диких тормозов,
>или ждут пока команда сработает секунт 10-30.

у меня имеено такие симптомы, но только при записи на usb flash (возможно и usb hdd)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Кракен , 06-Авг-10 21:25 
Как я понял, это не один баг. Просто проявляется аналогично. Там все в куче- железо, какие то регрессии, еще что-то. Есть всякие разные методы, которые одним помогают, другим нет. Можешь поискать, глядишь чего-нить да поможет. :)

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Вредоносный , 07-Авг-10 15:11 
>dd if=/dev/zero of=/some/file bs=8M

Запустил. Индикатор винта на моем ветре горит, файлик делает.
А я пишу это сообщение. ЧЯДНТ?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 07-Авг-10 15:16 
>>dd if=/dev/zero of=/some/file bs=8M
>
>Запустил. Индикатор винта на моем ветре горит, файлик делает.
>А я пишу это сообщение. ЧЯДНТ?

система должна, для начала, полезть в своп! (а потом уже пробовать dd)
она это делает?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено filosofem , 06-Авг-10 21:13 
Да смешно конечно.
Посмотрел, что ЛОРе предлагают, и в багзилле. Я такое уже делал и одновременно кино смотрел и никаких даже секундных подтормаживаний.
Короче ясно, это не мой случай. Убунта 10.04 и Debian lenny.


Вот я одного не могу понять, почему считается, что баг в ядре, если тормозят только DE и то не все? Может быть там какие-то десктопные фишки, которые 'file' регулярно запускают на измененном файле, или превьюхи пытаются генерить, или размер файлов подсчитывать "незаметно", не?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено аноним , 07-Авг-10 04:29 
или бигли и прочии индексаторы какие-нибудь стоят. я к примеру их сразу сношу.
описываемые траблы ниразу не встречал.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 19:00 
>[оверквотинг удален]
>понимаю о чем разговор. Ни разу не видел, чтобы на недревнем
>железе были тормоза из-за копирования. Объясните как репродуцировать проблему, какая файловая
>система должна быть, какое ядро, видяха, видеодрайвер, версия иксов, какой SATA(PATA)
>контроллер используется, какой чипсет в конце концов? Если это про ntfs-3g
> и iowait, то не интересно.
>А то так написано, как будто это повсеместное явления, а у меня
>ни на одном компе не наблюдается, я уже 10 dd запустил
>и в наутилусе копировал в несколько потоков и болванку нарезал одновременно
>и нормально десктоп работает.
>Правда иксы пропатченные, может быть в этом дело?

у меня эта штука проявлялась сразу после того как система в своп начинает лезть - при обработке большого видео проекта в cinelerra + большое колличество дисковых операций, например когда deluge чекал торренты... потом в "делуге" что-то поправили что бы он типа в один поток к винту обращался...
один раз пришлось даже reset нажать - потому что 45 минут ожидания при попытке перейти в консоль CTRL+ALT+F1 (что бы убить процесс душащий систему) не хватило терпения... :(


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено iss , 07-Авг-10 04:32 
Точно такие же пирожки, если памяти осталось пшик, то все замирает, приходится резет или MagicSysRq юзать, по другому баг не проявляется, диски/флешки нормально пишутся.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 21:11 
>А есть кто-нибудь, у кого эта бага не проявляется.

Поищи обсуждение этого бага, например на Опеннете. Увидишь, что он возникает в зависимости от железа и его драйвера чипсета.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ACCA , 06-Авг-10 21:25 
>А есть кто-нибудь, у кого эта бага не проявляется. Я вообще не

Ты походу хотел спросить у кого она проявляется. Я такого не видел со времён Pentium 4 HT.

Сегодня не поленился проверить - ни на одной доступной железяке воспроизвести не удалось.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено filosofem , 07-Авг-10 00:58 
>Ты походу хотел спросить у кого она проявляется.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено ононим , 06-Авг-10 22:00 
баг проявляется на чипсетах nforce(2, 4). я гарантирую это.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 22:04 
>баг проявляется на чипсетах nforce(2, 4). я гарантирую это.

у меня на ноуте Dell Vostro 1400 проявлялся - на других не замечал, но там  Intel чипсет...


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Кракен , 06-Авг-10 22:38 
nForce4 SLI - никаких проявлений в течении 4х лет.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 12:15 
>баг проявляется на чипсетах nforce(2, 4). я гарантирую это.

Кровью подпишешь?

-----------

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
02:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce GTS 250] (rev a2)
10:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
10:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
10:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
10:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01)
11:04.0 Co-processor: Broadcom Corporation BCM5820 Crypto Accelerator (rev 10)
80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:0a.0 Ethernet controller: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
81:00.0 Ethernet controller: Agere Systems ET-131x PCI-E Ethernet Controller (rev 02)


Надеюсь знаете, что CK804 - это nForce4? Так вот, сижу пишу эту хрень,
на консоли делается dd if=/dev/zero of=BIGFILE count=1024 bs=32M,  
ффокс играет ролик на утрубе при 1080p http://www.youtube.com/watch?v=HuD1X0QPhWM  
top показывает 18% утилизации на двух ядрах.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено utilitytrack , 08-Авг-10 03:32 
А RAM у вас сколько? А в своп что-нибудь сбрасывается или он пустой? К тому же в оригинальном тесте надо записывать по 1М за раз (а у вас 32М). А какие параметры в /proc/sys/vm/swappiness и /proc/sys/vm/vfs_cache_pressure? Так много вопросов потому что у меня тоже чипсет CK804. Проблема дает о себе знать когда заканчивается RAM (256M).

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 08-Авг-10 13:43 
>А RAM у вас сколько? А в своп что-нибудь сбрасывается или он
>пустой? К тому же в оригинальном тесте надо записывать по 1М
>за раз (а у вас 32М). А какие параметры в /proc/sys/vm/swappiness
>и /proc/sys/vm/vfs_cache_pressure? Так много вопросов потому что у меня тоже чипсет
>CK804. Проблема дает о себе знать когда заканчивается RAM (256M).

Да уж... 256 это ещё не минимум, но уже хреново. :)

------

dd if=/dev/zero of=BIGFILE count=32768 bs=1M
32768+0 записей считано
32768+0 записей написано
скопировано 34359738368 байт (34 GB), 131,577 c, 261 MB/c

------

RAM 4Gb DDR2 ECC PC3200 Registred

-----

vm.swappiness                  =  0
vm.vfs_cache_pressure          =  1000


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено edo , 06-Авг-10 21:03 
у меня при активной записи на usb flash (особенно в несколько потоков/на несколько flash) остальные приложения могут "подвиснуть" (судя по всему на io).

патч борется именно с этой проблемой?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 21:07 
>у меня при активной записи на usb flash (особенно в несколько потоков/на
>несколько flash) остальные приложения могут "подвиснуть" (судя по всему на io).
>
>
>патч борется именно с этой проблемой?

э-э-э-э с флешками это отдельная тема...
некоторые флешки просто не умеют в несколько потоков писать. а что после этого происходит - хз.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено edo , 06-Авг-10 21:11 
>некоторые флешки просто не умеют в несколько потоков писать. а что после
>этого происходит - хз.

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 06-Авг-10 21:57 
>>некоторые флешки просто не умеют в несколько потоков писать. а что после
>>этого происходит - хз.
>
>ну так пусть и тормозит запись на flash, к этой части у
>меня никаких претензий нет.
>только почему переключение на соседний xterm может занять несколько секунд? (в случае
>параллельной записи на две тормозные флешки)

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


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено edo , 07-Авг-10 09:57 
>потому что есть понятие очереди...
>и кто знает - что произойдет если вся очередь забьется кусками только
>для флешек?

разве не отдельная очередь для каждого блочного устройства?


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 07-Авг-10 11:33 
>>потому что есть понятие очереди...
>>и кто знает - что произойдет если вся очередь забьется кусками только
>>для флешек?
>
>разве не отдельная очередь для каждого блочного устройства?

я так понимаю что сразу это всё попадает в очередь планировщика ( noop anticipatory deadline cfq ) а уже потом в очереди блочных устройств...


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Зенитар , 06-Авг-10 21:12 

>некоторые флешки просто не умеют в несколько потоков писать

А почему же некоторые? АН flash-диски всегда нужно записывать данные только в один поток, и использовать не журналируемую файловую систему


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Валерьян , 07-Авг-10 00:55 
На домашней машине никогда этот баг не проявлялся, зато на рабочей такой тупняк даже когда система немного свопится - курсор не двигается, и этот патч кстати не помог.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 07:22 
Попробовал у себя. Забавно это все работает :)
Раньше периодически сталкивался с такими тормозами, но только сейчас дошли руки оттестить и локализовать проблему.
Eee pc 901, ssd, atom
Соответственно reiserfs, nolog, noatime, elevator=deadline, sd[a-b]->fifo_batch=1, vm.swappiness=0, swap off

xxx@xxxbook:~$ uname -a
Linux ormbook 2.6.30-02063010-generic #02063010 SMP Fri Dec 4 10:49:55 UTC 2009 i686 GNU/Linux

Запускал в два потока
sudo dd if=/dev/zero of=/home/test[12].tst bs=8M count=100
И смотрел на отзывчивость при работе с /home и в целом, наблюдал iostat 1 и vmstat 1

Выяснил примерно следующее:
1. Явно есть какие то гонки при одновременном доступе на запись нескольких потоков к одному устройству (в моем случае - sdb), на работе остальных дисковых устройств отражается несильно (sda например)
2. Суммарная скорость записи обоих потоков значительно (30% и больше) меньше чем скорость записи одного потока, что по идее на SSD быть не должно.
3. Если допустим в gedit открыт файл на редактирование (в /home естественно) и попытаться его сохранить, gedit зависает до окончания записи обоих потоков.
4. Если перемонтировать /home в sync, скорость записи несколько снижается. (спасибо К.О.! :) )
5. Но при перемонтировании в sync в том же gedit зависание происходит не до конца записи, а на 3-5 секунд. Т.е. появляется хоть какая то отзывчивость.
6. В любом режиме (и sync и async) из bash командами вида "echo xxx > /home/test.txt" или "cat /home/test.txt" все работает достаточно быстро, без тормозов.

Вывобы примерно такие - проблема в где то в записи метаданных. sync позволяет её несколько сгладить (очередь не успевает переполниться видимо). Проблема видимо возникает не при любой записи, а только при записи с определенными флагами (bash же не вис, вис только gedit, хотя может я ошибаюсь) - нужно посмотреть как именно выполняет запись gedit и как bash в исходниках и написать пару тестовых бинарников для проверки.

Для себя я решил просто поставить sync - флешка все равно умрет рано или поздно, +-30-40% скорости записи мне не роляют. А вот сидеть и ждать, пока какой нить образ на флешку зальется - весьма нехочется, были прицеденты.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено йло , 07-Авг-10 07:42 
>Для себя я решил просто поставить sync - флешка все равно умрет
>рано или поздно, +-30-40% скорости записи мне не роляют. А вот
>сидеть и ждать, пока какой нить образ на флешку зальется -
>весьма нехочется, были прицеденты.

вместо sync еще можно попробовать такой способ

echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 4096 > /sys/block/sda/queue/nr_requests
echo 4096 > /sys/block/sda/queue/read_ahead_kb
echo 100 > /proc/sys/vm/swappiness
echo 0 > /proc/sys/vm/dirty_ratio
echo 0 > /proc/sys/vm/dirty_background_ratio

проверено - у меня работает ))


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 10:41 
>echo 100 > /proc/sys/vm/swappiness

Ну это вообще не для меня. Как я писал, у меня ssd и свопа нет, крутить этот параметр смысла нет.

>echo 10 > /proc/sys/vm/vfs_cache_pressure

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

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

Тоже на SSD нахрен не нужно, у меня стоит 256 кв. Где то в инете было тестирование влияния RA при работе с SSD, я от него отталкивался.

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

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

>echo 0 > /proc/sys/vm/dirty_ratio
>echo 0 > /proc/sys/vm/dirty_background_ratio

Посмотрим, может что и родится.

>проверено - у меня работает ))

Что то у меня ощущения, что у тебя работает в силу других причин, или просто тестишь неправильно. Ибо из того, что ты назвал - может влиять на эту проблему (в варианте как описал я) - только может быть nr_requests,dirty_ratio,dirty_background_ratio


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 13:11 
>>echo 100 > /proc/sys/vm/swappiness
>
>Ну это вообще не для меня. Как я писал, у меня ssd
>и свопа нет, крутить этот параметр смысла нет.
>
>>echo 10 > /proc/sys/vm/vfs_cache_pressure
>
>Опять же, как я понял этот параметр как и предыдущий работает только
>если есть своп.

Не, это VFS

vfs_cache_pressure
------------------

Controls the tendency of the kernel to reclaim the memory which is used for
caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt to
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
never reclaim dentries and inodes due to memory pressure and this can easily
lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
causes the kernel to prefer to reclaim dentries and inodes.


>>echo 4096 > /sys/block/sda/queue/read_ahead_kb
>Тоже на SSD нахрен не нужно, у меня стоит 256 кв. Где
>то в инете было тестирование влияния RA при работе с SSD,
>я от него отталкивался.
>
>>echo 4096 > /sys/block/sda/queue/nr_requests
>
>Потом потестирую, может быть как нить влияет. Кто нить знает, как посмотреть
>сколько запросов в очереди дискового шедулера к устройству sda в данный
>момент времени? Было бы интересно помониторить при нагрузке.

Sadomazo версия
# cat /proc/diskstats

Классика
# iostat -x

>>echo 0 > /proc/sys/vm/dirty_ratio
>>echo 0 > /proc/sys/vm/dirty_background_ratio

0 - это сурово :)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 18:26 
>[оверквотинг удален]
>------------------
>Controls the tendency of the kernel to reclaim the memory which is used for
>caching of directory and inode objects.
>At the default value of vfs_cache_pressure=100 the kernel will attempt to
>reclaim dentries and inodes at a "fair" rate with respect to pagecache and
>swapcache reclaim.  Decreasing vfs_cache_pressure causes the kernel to prefer
>to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will
>never reclaim dentries and inodes due to memory pressure and this can easily
>lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
>causes the kernel to prefer to reclaim dentries and inodes.

Что и требовалось доказать - если нет свопа, значит и конкуренции между "dentries and inodes" и "pagecache and swapcache" нет. Т.е. если все действительно работает как написано (что вовсе не есть факт) - разницы от кручения этого параметра быть не должно.


>>Кто нить знает, как посмотреть
>>сколько запросов в очереди дискового шедулера к устройству sda в данный
>>момент времени? Было бы интересно помониторить при нагрузке.
>Sadomazo версия
># cat /proc/diskstats
>Классика
># iostat -x

Спасибо


>>>echo 0 > /proc/sys/vm/dirty_ratio
>>>echo 0 > /proc/sys/vm/dirty_background_ratio
>0 - это сурово :)

Вот и мне показалось несколько подозрительным. Тестить надо =)

Кстати покопавшись в крутилках, подумал что в моем случае (нетбук на atom и ssd без свопа, fs в sync) имеет смысл уменьшить /sys/block/sd[ab]/queue/iosched/write_expire до 2500 с дефолтных 5000, или даже меньше (например 2000 или 1500).
Но пока только поставил, еще не тестил.

Как я понял, write_expire в моем случае и есть максимальное время, на которое может зависнуть тот же gedit при записи файла на раздел, на который уже ведется интенсивная запись в другом потоке.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено pavlinux , 07-Авг-10 20:02 
>>[оверквотинг удален]
>Что и требовалось доказать - если нет свопа, значит и конкуренции между
>"dentries and inodes" и "pagecache and swapcache" нет.

Своп - это нечто иное как продолжение Виртуальной памяти.
vm.swappiness - задаёт вероятность включения в работу дискового свопа.
И не надо его боятся, при данном параметре, от 0 до 10, своп заработает
только при полном заполнении оперативки.  

........

Эх, надо ФАК написать по sysctl -w vm.*


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 20:57 
>>>[оверквотинг удален]
>>Что и требовалось доказать - если нет свопа, значит и конкуренции между
>>"dentries and inodes" и "pagecache and swapcache" нет.
>Своп - это нечто иное как продолжение Виртуальной памяти.
>vm.swappiness - задаёт вероятность включения в работу дискового свопа.
>И не надо его боятся, при данном параметре, от 0 до 10,
>своп заработает
>только при полном заполнении оперативки.

Да в общем то словоблудие все это.
В моем случае свопа нет и он не нужен. Плюс это лишняя неизвесная в работе системы (в которой судя по комментам к 12309 есть баг, проявляющийся при нагрузке).
Вопрос только, насколько корректно в подсистеме vm обрабатывается случай отсутствия свопа вообще, и соответственно насколько полно отключаются куски кода, не нужные в данной ситуации (а в данном случае - еще и потенциально тормозящие и имеющие баг). Все таки отсутствие свопа - не совсем стандартный случай ;)

>Эх, надо ФАК написать по sysctl -w vm.*

Напиши, я думаю многим не хватает толкового описания на понятном русском как работают эти крутилки. Особенно с примерами из практики, что на что влияет ;)


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 20:47 
Потестил еще
Выяснил интересный момент, не очевидный с первого взгляда.
У меня (atom, ssd, fs sync) параметр fifo_batch стоял в 1. Выяснилось, что если его вернуть в дефолтные 16, скорость линейной записи в ОДИН поток возрастает примерно в два раза, а на отзывчивости и на записи в два потока это сказывается несильно - как зависал gedit на 5-10 секунд, так и виснет, скорость двух потоков тоже меняется не более чем на 10%.

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

В общем странно.
Учтите это, если у кого будет похожая конфигурация (sync fs, elevator=deadline).

P.S. nr_requests c дефолтных 128 увеличил до 512, его длины явно не хватало как я понял из iostat. На результатах заметным образом это не сказалось.


"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 14:57 
2.6.35 патч не помог если память кончается и ядро лезет в своп начинаются жуткие тормоза, курсор тормозит, выод картинки в tvtime тоже, загрузка проца не более 40%, комп старый амд 1,6 ГГц 1,25 Г память, чипсет VIA.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено filosofem , 07-Авг-10 17:42 
Если это и баг, то из другой оперы совершенно. ИМХО если оперативка заканчивается и все начинает тормозить и нагрузка на диск резко возрастает из-за свопа, это вполне нормальное явление.
Здесь вроде бы просто про активные дисковые операции разговор.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено Аноним , 07-Авг-10 21:08 
>Если это и баг, то из другой оперы совершенно. ИМХО если оперативка
>заканчивается и все начинает тормозить и нагрузка на диск резко возрастает
>из-за свопа, это вполне нормальное явление.
>Здесь вроде бы просто про активные дисковые операции разговор.

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

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



"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено filosofem , 08-Авг-10 00:33 
Bug 12309 -  Large I/O operations result in poor interactive performance and high iowait times
Это не про своп на границе исчерпанной памяти. То что свопинг может вызвать Large I/O operations это понятно. Но там где именно этот баг, проявляться он будет не только при свопе.
Ну а то что все похожие тормоза начали обзывать багом 12309, это я уже понял  и об этом и написал. И кстати представленный патч насколько я понял не помог никому, у кого действительно Large I/O operations вызывают тормоза, а не закончившаяся оперативка.

"Патч, решающий проблемы с отзывчивостью Linux-десктопа"
Отправлено fidaj , 08-Авг-10 12:19 
>Если это и баг, то из другой оперы совершенно. ИМХО если оперативка
>заканчивается и все начинает тормозить и нагрузка на диск резко возрастает
>из-за свопа, это вполне нормальное явление.
>Здесь вроде бы просто про активные дисковые операции разговор.

это далеко не нормальное явление!
операции со свопом - дисковых операций тоже касаются.
так что проблема одного характера...