Dotaz: AHCI způsobuje vyšší vytížení procesoru

[tobik]

Všiml jsem si, že udev (/sbin/udevd --daemon) mi běžně zabírá 10-15% procesoru. Po čase jsem zjistil, že stačí vypnout v biosu AHCI. S tím se ale zase nesmíří Windows v dualbootu (skončí BSOD).

Našel jsem sice, co AHCI je, ale nepochopil jsem, jaký přínos to pro mě může mít :) Jestli to stojí za těch 10-15% výkonu. A samozřejmě měnit bios při každém rebootu také není ideální. Přirozeně nejlepší by bylo upravit nastavení udevu tak, aby i při zapnutém AHCI zabíral pouze běžných 0-1%, ale to právě nevím jak.

OpenSuse 11.2, kernel 2.6.31.12

Odpovědi

[Semo]

Pozri logy jadra a udevu, pripadne mu zvys logovanie. Asi sa ti tam nieco mlati. Udev by nemal v podstate robit nic, ak sa nemeni hw. Aj to 1% je skoro privela. Pripadne skus zmenit verziu udevu.

[tobik]

Nastavil jsem si logování udevu na info a moc moudrý z toho nejsem. Smazal jsem /var/log/messages a restartoval počítač. Hned po restartu měl /var/log/messages 11MB a po několika minutách už 50MB. Naprostou většinu z toho mají na svědomí zprávy udevu. http://pastebin.com/7hKuv25s tady je úryvek. Zdá se mi, že se to pořád opakuje.

No než jsem napsal těchto pár řádek, už má log 80MB

[Semo]

Asi by to chcelo kus logu z konca alebo prostriedku a nie zo zaciatku, kde ako sam vidis 200kB sa vygeneruje aj bez AHCI. udev bude asi stale nieco skusat a stale failovat. Takze chces najst nejake opakujuce sa logy o tom istom a potom mozes hladat, preco sa mu nedari.

[tobik]

http://tobik.pastebin.com/Jgmace8s

Nepodařilo se mi vysledovat, který kód se tam přesně opakuje (kde začíná, kde končí), ale že se to opakuje je zřejmé třeba podle tohoto úseku, který je poměrně výrazný a nepřehlédnutelný:

Apr 24 17:37:11 redBook cdrom_id[1492]: CDROM_DRIVE_STATUS != CDS_DISC_OK
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_CD_R=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_CD_RW=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_DVD=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_R=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_DVD_RAM=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_MRW=1'
Apr 24 17:37:11 redBook udevd-work[374]: '/lib/udev/cdrom_id' (stdout) 'ID_CDROM_MRW_W=1'

[NeoV]

Bude chyba v jadre - teda nekompatibilny/zabugovany ovladac SATA radica... pri 2.6.31 jadre mi to s mojim southbridge-om SB700 robilo tiez sarapatu --> po pripojeni jedneho z ext. USB diskov... udev hltil log errormi... po upgrade na Kubuntu 10.04 s jadrom 2.6.32-21 problem uplne zmizol

takze som to neriesil nejako vyraznejsie...

[Semo]

Skus inu kombinaciu udev a jadro (su navzajom na sebe dost zavisle a nefacha kazda verzia s kazdou). Nemas nejak zacyklene pravidla?

[tobik]

Pravidla udevu jsou výchozí od opensuse, jediné pravidlo, které jsem si ručně vytvořil, rozpozná můj externí disk a vytvoří na něj speciální symlink v /dev. Nedokážu si představit, jak by se to mohlo zacyklit. A navíc pouze se zapnutým AHCI.

S tím kernelem už jsem to začal zkoumat, ale bohužel opensuse se nezdá k této cestě otevřené. Existují sice předpřipravené balíčky s novějším kernelem, ale balíky s odpovídajícími moduly už ne. Konkrétně preload-kmp-desktop mi dělá problémy. A ručně to kompilit proti novému kernelu mi přijde příliš krkolomné.

[tobik]

No tak s vypnutým AHCI má log najednou po spuštění 200 kB a dál už se vůbec nehýbe.