Вы здесь

Главная › Форум › Gentoo Linux › Ядро Linux и поддержка оборудования

опять про iowait bug

5 марта, 2010 - 17:24 — petrun

Предыстория :
Ох и намучался же я с ним.Запись в один поток на диск - терминал открывается 5-10 сек, в несколько потоков - можно идти пить чай.
История :
А вчера решил поставить libre сорцы(с вырезанными блобами, все из себя свободные), просто ради интереса, глянуть заведется ли что-нибудь.
И, о чудо, баг исчез.Нет, при записи в несколько потоков интерактивность системы несколько снижается, но видимо дело только в забитом дисковом кеше.
Сейчас занят изучением diffа, но пока ничего полезного не нашел.Из меня сомнительный программист, так что знающим, и тем кому этот баг просто сильно надоел прошу помочь.

% uname -a
Linux petrun-home 2.6.33-libre #3 SMP PREEMPT Fri Mar 5 15:47:34 MSK 2010 x86_64 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz GenuineIntel GNU/Linux

Ни с gentoo, ни с zen, ни с ванильными сорцами такого нет.

Форум: 
Ядро Linux и поддержка оборудования
5 марта, 2010 - 19:03 — haku

Имхо не обязательно именно libre. Всё дело в верси ядра.
В патчнотах 33-го было указано, что алгоритм работы CFS был оптимизирован для условий высокой нагрузки на i/o подсистему.

Вы попробуйте =sys-kernel/gentoo-sources-2.6.33 , долно быть так-же.

5 марта, 2010 - 19:16 — petrun

Я,наверное, неправильно выразился.В том-то и дело, что в других доступных *.33 не так же.

5 марта, 2010 - 19:29 — ananazzz

не помню где, случайно в сети наткнулся на такую рекомендацию:

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

проблем почти ноль. но если не задействуется своп. если начнет юзаться - будет то же самое что с дефолтными значениями (60 и 100 соответственно), на работу можно забить :) конечно это если своп, система и остальная свалка на одном диске. на разных еще не доходило как то проверить.

5 марта, 2010 - 19:37 — petrun

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

5 марта, 2010 - 22:45 — evadim

У меня нет swap и 8 гиг оперативы - и оно тупиииииит. понятно что когда используется swap оно ещё больше тупить будет, но...

6 марта, 2010 - 05:40 — willy

Парни, подскажите, как воспроизвести данный "тупёж" системы?
Сейчас поставил систему на бэкап с помощью rsync - светодиод, индицирующий
работу дисков просто горит, даже и не думает моргать.
При этом я вполне себе комфотрно сижу в иксах, музЫка играет без рывков, консоли и всякая
дребедень открываюстя без тормозов... ЧЯНТД?
ядро: 2.6.32-gentoo-r5

6 марта, 2010 - 07:20 — inspirra

А разве этот тупняк был не только на nForce чипсетах со сломанным ADMA?
http://bugzilla.kernel.org/show_bug.cgi?id=12309
http://osdir.com/ml/linux-kernel/2009-04/msg02590.html
Или речь о другом тупняке?

6 марта, 2010 - 08:25 — willy

Я думаю, что в их случае сильно эксплуатируется "южный мост", при чём не только
дисковой подсистемой, а - сетевыми гигабитными карточками, например или встроенным
звуковым кодеком. Вся эта свора процессов, требующая активного доступа к PCI шине
терзает "южанина", вот мы и получаем "и-о-вайт буг"
Хотя, мо-быть я и не прав ;)

6 марта, 2010 - 08:37 — evadim

Речь именно о том баге что на kernel.org но, если почитать то что там написано проблема не в энвидиевском мосте, не в сорте планировщика и не в NCQ, хотя всякие танцы с бубном отодвигают слегка этот баг. Предпоследний на этот момент комментарий «доставляет».
UPD ещё написано что баг провоцируют java софтины, возможно мою ситуацию усугубляет то что я использую торрент-клиент Vuze который на яве и там сотни две торрентов, пару месяцев назад я даже игрался с ulimit на предмет открытых файлов.

6 марта, 2010 - 08:28 — evadim

у меня тупняк возникает при svn up больших репов, типа оверлея сабайона, но только в момент после запуска синхронизации и до момента когда svn начал что-то выводить на экран, менее жёсткие тупняки когда копирую что-то большое на флэшку или другой винт, при emerge --sync во время регенерации кэша.

6 марта, 2010 - 10:07 — willy

evadim, как я понимаю Вашу ситуацию: Во время синхронизации svn идёт
интенсивный обмен пакетами + поиск по базе данных на локальном диске, что
тоже сильно грузит "хонтийца" (южный мост)? Что-то мне сдаётся, что
тут ядро-то и не при чём, собственно.
З.Ы: могу лишь предложить зайти на сайт производителя вашей мать-платы,
посмотреть обновления BIOS, как-либо связанные с улучшениями режима
DMA, после чего - сами знаете, что делать :)

7 марта, 2010 - 14:44 — evadim

BIOS стоит последний, только проблема появилась после очередного обновления ядра, давным давно. И вообще к такому эффекту приводит именно большая нагрузка на hdd. Новых версий BIOS'а нету.

6 марта, 2010 - 08:59 — lexa_

На ядрёной багзилле высказывалось мнение что этот баг проявляется только на x86_64. У когонить на x86 эта бага проявляется?

—

Кажеться пахнет булочками ...

6 марта, 2010 - 11:55 — Sith

lexa_ написал:
На ядрёной багзилле высказывалось мнение что этот баг проявляется только на x86_64. У когонить на x86 эта бага проявляется?

кстати да, после смены железа с P4 на CoreDuo и перехода на х86_64 стал замечать такую ерунду, до этого все было отлично.

—

________________________
"We Will Win"

6 марта, 2010 - 14:36 — lexa_

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

—

Кажеться пахнет булочками ...

6 марта, 2010 - 23:36 — petrun

lexa_ написал:
Я бы очень попросил страдальцев имеющих данные проблемы на x86 отписаться, чтоб укрепить/разрушить мою уверенность в том что это x86_64 специфичный косяк.

У меня на x86 никаких проблем нет.На x86_64 есть.

7 марта, 2010 - 00:01 — lexa_

На одном и том-же железе?

—

Кажеться пахнет булочками ...

7 марта, 2010 - 00:49 — petrun

да.Core i7 960, мать на p55(gigabyte P55-UD3), 4 гига памяти.

7 марта, 2010 - 13:57 — lexa_

Может это связано с использованием контроллера ICH10 ?

—

Кажеться пахнет булочками ...

7 марта, 2010 - 15:02 — haku

Нет, не в ICH10 дело. На контроллере от nvidia (MPC55) баг тоже есть. Точнее на ядрах 26-31 был, 32-ое не ставил. Выражался в диком тупняке системы при копировании больших файлов между разными hdd. Сейчас на 33-м всё гладко, процентов на 95 это баг то-ли исправлен, то-ли скрыт. Надеюсь всё-таки исправлен.

7 марта, 2010 - 15:25 — lexa_

Ну у меня он и на 33 ядре есть, и даже не при копировании больших файлов возникает а иногда спонтанно.
Включил block_dump(echo 1 > /proc/sys/vm/block_dump)(если будете так делать отключите сислог, или направле klog в консоль а не на диск), чтоб смотреть кто на диск пишет, однако во время фриза никакой особой активности дисковой ненаблюдалось, а лампочка на диске горит. Такчто я во всём виню контроллер.
P.S. с выключенным NCQ вроде стало получше, но это не лекарство.

—

Кажеться пахнет булочками ...

7 марта, 2010 - 16:45 — haku

Знаете, я тут вспоминал что ещё я в конфиге ядра менял при переходе с 31 на 33, и вспомнилось вот что, было:
Kernel hacking ---> IO delay type (port 0x80 based port-IO delay [recommended])
стало:
Kernel hacking ---> IO delay type (no port-IO delay)

может это и ересь, но почему бы и нет? Попробуйте.

7 марта, 2010 - 19:15 — lexa_

Скажите пожалуйста своё железо(особенно интересен контроллер) и конфиг ядра.

—

Кажеться пахнет булочками ...

7 марта, 2010 - 22:58 — haku

zcat /proc/config.gz
lshw

nVidia MCP55 sata, модуль ядра sata_nv

6 марта, 2010 - 12:20 — taaroa

petrun написал:
Предыстория :
[skip]

% uname -a
Linux petrun-home 2.6.33-libre #3 SMP PREEMPT Fri Mar 5 15:47:34 MSK 2010 x86_64 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz GenuineIntel GNU/Linux

Ни с gentoo, ни с zen, ни с ванильными сорцами такого нет.

Это заговор корпораций против Linux, очевидно же. =)
Однако в RHEL с кучей бэкпортов (и блобов) и ядром 2.6.18-53.1.19.el5 подобных проблем нет.
Данная тема уже становится неким баяном, в рассылке

неоднократно поднималась, предлагались разные решения, высказывались разные гипотезы о природе сего явления.

6 марта, 2010 - 13:59 — Sith

taaroa написал:
Однако в RHEL с кучей бэкпортов (и блобов) и ядром 2.6.18-53.1.19.el5 подобных проблем нет.

Вот на CentOS 5 (тот же RHEL 5) те же проблемы

—

________________________
"We Will Win"

6 марта, 2010 - 14:32 — taaroa 

┌(root@taaroa)┌(427/pts/4)┌(05:44:03/06/10)┌-
└┌(#:~)┌- uname -rms
Linux 2.6.32-hardened-r4 x86_64
(root@dorje)┌(477/pts/3)┌(05:44:03/06/10)┌-
└┌(#:~)┌- uname -rms
Linux 2.6.31-hardened-r9 x86_64

Все работает просто замечательно (хотя, наверное может и еще лучше).
А подобные Вашей ссылки мало о чем говорят, что то у кого то как то... кстати из той же ссылки, там товарищ обновил ядрышко ("обновился до версии CentOS 5.3, 2.6.18-128.el5") и проблемы "магически" отпали.

6 марта, 2010 - 23:37 — petrun

taaroa написал:
petrun написал:
Предыстория :
[skip]

% uname -a
Linux petrun-home 2.6.33-libre #3 SMP PREEMPT Fri Mar 5 15:47:34 MSK 2010 x86_64 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz GenuineIntel GNU/Linux

Ни с gentoo, ни с zen, ни с ванильными сорцами такого нет.

Это заговор корпораций против Linux, очевидно же. =)
Однако в RHEL с кучей бэкпортов (и блобов) и ядром 2.6.18-53.1.19.el5 подобных проблем нет.
Данная тема уже становится неким баяном, в рассылке

неоднократно поднималась, предлагались разные решения, высказывались разные гипотезы о природе сего явления.

Так 2.6.18 же.Кажется проблема позже появилась.Видимо не те бэкпорты)

7 марта, 2010 - 14:38 — evadim

petrun написал:
Так 2.6.18 же.Кажется проблема позже появилась.Видимо не те бэкпорты)

Вроде того.

7 марта, 2010 - 15:32 — krigstask

Три системы на amd64, никогда не замечал. Везёт мне, однако.

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

7 марта, 2010 - 18:47 — lexa_

Можно узнать какие материнки(в основном интересно какие диковые контроллеры используются)?

—

Кажеться пахнет булочками ...

8 марта, 2010 - 00:46 — krigstask

В профиле всё железо на основных машинах указано (-:Е

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

8 марта, 2010 - 10:57 — lexa_

Покажите пожалуйста конфиг ядра вот с этой машинки: AMD Athlon64 3000+, 2 Гб DDR, ESI Juli@, nVidia GeForce 7600 GS @ ASUS K8N-VM

—

Кажеться пахнет булочками ...

8 марта, 2010 - 13:01 — krigstask

Цитата:
% wgetpaste -s ca -c 'zcat /proc/config.gz'
Your paste can be seen here: http://pastebin.ca/1828361

—

Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal