【Linux】カーネル総合5【Kernel】

>>948
>カーネル単体で置き換えてしまって
って書いてあるから、ドライバとかライブラリとかなにもしないつもりってことじゃないのん？

カーネルの起動はユーザランドにベッタリ依存してるから
カーネルだけ大きくバージョン上げたら起動しない

2.6.12→39だと.config次第で/dev/hd??が/dev/sd??に変わってたりしないか？
pataでlibataが優先されるようになったのっていつからだっけ？ここ注意かもね

むしろ、古いata_piixでは新しいインテルのコントローラを認識しないんで、
SATAをBISOでIDEにして、
/dev/hda:
Timing buffered disk reads: 4 MB in 3.67 seconds = 1.09 MB/sec
こんな思いをさせられる場合がある。新しいlibata, ata_piixにしちまえよ。

>>932
ディストロごとアップグレードすべきかと
udevとかがカーネルのバージョンに依存してるところあるからね

DebianSargeから順番にアップグレードして現在Squeezeのマシンがあるけど、
Etchの段階で2.6.18から2.6.38.6しても大丈夫だった。

DiskまわりはDebianの場合、この辺に書いてあるみたいですな。
(UUID使うのはUbuntuとかも同じみたい)
http://debian.fam.cx/index.php?Software%2FLinuxKernel#uef8f38d

それにして、おおutrace、死んでしまうとはなさけないorz
[kernel] adios utrace.
http://lists.fedoraproject.org/pipermail/scm-commits/2011-May/602431.html

http://people.redhat.com/roland/utrace/
Rolandさんのページがなくなっちゃったので、もはや「アディオス」なのか
（チャオではないので、永遠のお別れ、といったところ...か）

swap用のパーティションにだけUUIDがついてなくて、
fstabの設定でまごつくでござる　の巻

>>954
debianの場合、ahciにしないと/dev/hd*のままだったな
変わると聞いて/dev/sda*にしたらむしろ起動しなくなった

nolapic_timer って具体的になにをするオプションなの？

local apic (各CPU固有) の timer を使わなくなる
そのかわりシステム全体のタイマでエミュレート

>>963
ありがとう
仮想マシンとか使うときはこれ指定しないほうがいいってことか

BKLが便利に使われ過ぎだろ…
何をロックしたいのか、わからん
再帰的ロックが必要なのか、わからん
どこからどこまでクリティカルセクションなのか、わからん
コメントがないから本当に必要なロックかすら、わからん
サードパーティ向けのパッチ書くのが面倒だー！！

re-introduce BKL

BKLは最近ので無くなったんじゃないの

うん
http://sourceforge.jp/magazine/11/05/20/115221

2.6.39で完全に逝ってしまわれたようだけど、
鳥によっては、それ以前でも無効にされてるのもあるみたい。
カーネル上げたら、周りのドライバがコンパイルできなくて困った。

そういうのはマ板でやってくれないかなあ。

>>970
ここでやらずにどこでやるんだよ・・・

BKL使いまくってた腐ったサードパーティードライバが無くなるかと思うと胸熱
…今度はsemaphore使いまくりですね分かります

spinlockの方かもしれない。
lock_kernelがそのままspin_lockに置き換わってたりするけど、いいのかな。
この辺りの使い分けは、どういった基準があるんだろ？

spin_lockとかはなるべく使わないようにしましょうってことでしょう

>使い分け
これが最新。mutex_lock_nestedはまだドキュメント化されてないようだけど。
Unreliable Guide To Locking
http://www.kernel.org/doc/htmldocs/kernel-locking.html

raw_spin_lock*も抜けてるな

おぉ、ありがとう！
ドライバになると、使う場所によっても考慮しなくちゃならないのは、ちょっと面倒くさいね。

raw_spin_lockって直接使うもの？spin_lockの実装に使うものかと思ってたよ。

そういや、この辺り調べてたら、unlocked_ioctlとか見つけた。ioctlとどう違う？
BKLを排除したいがために導入されたようだけど、
あるドライバのunlocked_ioctlの実装は中でBKL使ってるんだよね…どういうことなの…？

>>977
spin_lockはPREEMPT_RT (リアルタイムカーネル)の時にmutexになるけども、raw_spin_lockだとならない
なのでIRQスレッド化の状態でもmutexにできないspinlockに使う
…と認識してたけども、IRQスレッド化がブートオプションになったので、合ってるか自信無い。

それとunlocked_ioctlについては、元々BKLかけてから.ioctlが呼び出されていたので、
BKL削除のためにBKLをかけないで呼び出す.unlocked_ioctlが作られた
(.unlocked_ioctlの内でBKLを使ってたのは一時的)

そーなのかー。ありがとう。
ドライバが動かなくなったときに何とかしようと、
ソース読み始める程度の人にはついていけないわ…変化が激しい

spin_lock_irqsaveで割り込み禁止しちゃっても、そのraw_spin_lockの代わりにならない？

unlocked_ioctlってそういうことだったのね。じゃあ、今日までその中でBKL使ってたドライバって…orz

全く違う話だけど、カーネル2.8/3.0に本当になるのかな。
もうできる限りABIもAPIも変わって欲しくないから、大規模な改修はそっちでやってくれないかな。
でも、リーナス的には、もうバージョンで安定版、開発版って分ける気はないようだ。

>変化が激しい
そこが面白い所なんだけどなw

>spin_lock_irqsave
PREEMPT_RTを有効にすると、レイテンシを下げるためにspin_lock_irqsaveなどもmutexにしちゃう
なのでスリープできないところにraw_*を使う (IRQはthreadirqsでスリープ可能になる)。
…ただSleeping spinlocksはまだマージされてないので、mainlineだと有効にはできないけども。

なんだかんだあって、結論としてはほぼイケました。
initrd中の/sbin/initの完走、そしてpid 1のほうのinitの完走。
数年前の鯖からHDD引っこ抜いて最近の鯖に入れたため、
心機一転make defconfigでカーネルを作成。mkinitramfsなどなく、
mkinitrdしかないので、initrd無しでいっちゃえないか、と思ったがダメ。
Kernel panic - not syncin: VFS: Unable to mount root fs on unknown-block(2,0)が出てダメ。
/bootと/が別パーティションだとダメなのか？よく分からない。結局initrdはmkinitrdで作る。
すると、この問題だけはパスできる。

その後、そこから先へ進むものの、途中で止まる。
syslog見ると、init: open(/dev/console): No such file or directoryと出てる。
2.6.13移行はdevfsが無くなった？ので、2.6.12で動かしていたシステムは痛い目見ることに。
/etc/rcS.d/の辞書順最初の方にあり、呼び出しているudevスクリプトを書き換え、
tmpfsを/devにマウントし、udevstartが呼ばれるまでの間に、mknod連発。
mknod -m 660 console c 5 1
mknod -m 666 null c 1 3
これで概ね起動するようになるものの、ログインプロンプト出ず。
ttyもズラズラと追加。すると、ログインプロンプト出る。一安心。

あとはsshが動いていなかったり、ホットプラグが正常じゃなかったり（デバイスノードが作成されない）。
まっとうなやり方だと、いつデバイスノードを追加するもんなのですか？
起動前から繋がっているデバイスを、どうやってudevは認識するのでしょうか。
また、今ホットプラグが正常じゃないのは、どうもsysfsの様子が変わってしまって、
今あるudevのrulesが適応できてない感じです。BUS=などの情報が報告されてないような気がしてなりません。
udevinfo -a -p /sys/block/sda/sda1
SUBSYSTEM="block"　以下略
こんなのが出るだけで、BUSの情報が上がってきていません。最近のカーネルのはこんな感じなんですか？

>>980
spin_lockって書くとmutexになる
Linuxはいつもそうだ
わけがわからないよ

僕と契約してspin_lock_maybe_mutexになってよ！

ロックの性能を気にするんなら、adaptive lockも入れて欲しい。
昔話題になったような…消えたのか？

>>983
38だが動いてるので、とりあえずudevは新しいのが入ってるよね？

adaptive lock言いたいだけちゃうんかと

はははっｗ　ありがとう

>>984
"ハードRTの人たちは真っ当な理由でうまく機能を導入するけども、私は未だに彼らがおおかた狂ってると思ってる"(意訳)ってライナスが言ってた>わけがわからないよ
"一緒に作業できるから問題ない"とも

>adaptive lock
昔話題になったのは通常のmutexで、それは既にadaptiveになってる
spin_lock*がPREEMPT_RTで化けるmutex(rt_spin_lock/sleeping spinlock)もadaptiveになってる
rt_mutex(優先度継承付きmutex)はadaptiveになってないかも?

…rt_mutexとrt_spin_lockの違いとその意味について理解できてないや

>>983
ばっちゃんの遺言に従え

>>987
なるほど、勉強になる。Linusらしいなあｗ

realtime preemptionがマージされたのは、まだ一桁の9ごろだったか、もう6年前か。
あのころ、少しずつマージしていくって聞いたけど、まだやってるんだ。大変だ。

リアルタイムって聞くと、組み込みイメージするけど、デスクトップにも恩恵あるのかな？
まあ、驚くほど恩恵があればLinusがそう言わないだろう。
PulseAudioは、リアルタイムに設定しないと音がバグるとか、マルチメディア関係には必要？

組み込みにしても、どんなハードでも有効に出来たっけ。ハードに依存する所が多そうなんだけど。
ほんと、よくわからない。　（ここって結構人居たんだね）

>>984
linuxのロックは宇宙のエントロピーを軽く凌駕しているね

【Linux】カーネル総合6【Kernel】
ttp://hibari.2ch.net/test/read.cgi/linux/1306521430/

>>989
ハードリアルタイム自体はデスクトップ環境には不要だと思う (消費電力やスループット的に考えて)。
ロックレス化が進めばソフトリアルタイムのワーストレイテンシも改善されるはずだし。
RTで実装された幾つかの要素は、デスクトップにも恩恵をもたらしてるしこれからももたらすと思う。

マルチメディアに関しては、現状RTカーネルが使われるのは、通常のカーネルだとjackdがxrun起こすから (レイテンシが足りない)。
この問題はソフトリアルタイム(+rt-mutex)+deadline系のスケジューラー(IRMOS Schedulerとか)で解決されるべきかと。
あと、firewireのオーディオドライバはユーザー空間じゃなくてカーネルにあった方が良いねぇ。

>どんなハードでも有効に出来たっけ
ハードやBIOS設定などによってレイテンシが大きく異なる。それとロック周りの変化に伴うバグの問題も。

割り込みハンドリングのスレッド化って、レイテンシ性能的にどうなん？
スループット上げるのが目的ならいいんじゃないかって気はするんだけど。

>>988
ばっちゃんの遺言にだけは従えぬ事情があるのです…。
カーネルと最小限だけを、アゲたいのです…。

>>984
udevは2.6.12当時のものですんで、
udevinfo -Vはudevinfo, version 056です。

39のsysfsを、056udevが扱いきれてないのでしょうか。
12のsysfsでは、056udevでホットプラグ正常です。多分。
udevtestすると、ちゃんと用意されてるルールを適用しようとしています。

>>994
こんな言い方すると感じ悪いのは承知だけど、
自分ルールでKernel更新するのにドキュメントも読まないで人に聞くとか、甘えすぎだと思う
もっかいDocumentation/Changesちゃんと読めよ

>>994
http://ja.wikipedia.org/wiki/Udev

$ uname -r
2.6.38.6-27.fc15.i686.PAE
$ udevinfo
bash: udevinfo: command not found...
$ udevadm --version
167

>>996
他の2.6.32-5-686環境で確認するとudevは164でした。
# udevadm info -a -p /sys/block/sda/sda1/
# udevadm info -a -p /sys/class/input/mouse0
などしてみると出るわ出るわ。056と違って饒舌に情報をくれます。
これならルールもいろいろ書けそうなんですが。
やっぱ古いudevと新しいカーネルの組み合わせは鬼門のようです。
なにかうまくいったら次スレにでもチョコッと報告します。ありがとうございました。

>>993
そもそもがリアルタイム優先度のスレッドのレイテンシを改善するために、IRQをスリープ可能なスレッドにして後回しにするって話。
スループットがあがるかというと、余計な処理が増えて基本下がるはず。
sleeping spinlockが入れば上がる場合が出てきてもおかしくないけども、ロックレスになるまでの一時的なものだと思う。

999

１０００

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。