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

【Linux】カーネル総� ..

732:login:Penguin
09/06/20 14:13:18 scxDjYjs
>>730
トラ技5月号あたりの
新入社員向け特集で毎年出てくる。

733:login:Penguin
09/06/20 20:40:19 MZ+4ddd0
DaveM が page allocation failureのメッセージうざいから、warning出すのやめようぜ。って言ってるけど、使ってる奴ほんとにいないの？

734:login:Penguin
09/06/21 23:29:12 VQh+3f2H
カーネル的にはQPI接続のNUMAなi7 Xeon構成には対応してるの？

735:login:Penguin
09/06/21 23:34:37 GKm9ryra
opteronのころから対応してるでしょ

736:login:Penguin
09/06/22 00:05:07 gHVjWzz2
>>735
CONFIG_NUMA: │ Enable NUMA (Non Uniform Memory Access) support.
│ The kernel will try to allocate memory used by a CPU on the
│ local memory controller of the CPU and add some more
│ NUMA awareness to the kernel.
│ For 64-bit this is recommended if the system is Intel Core i7
│ (or later), AMD Opteron, or EM64T NUMA.

そうみたい。S5500HCV買ってくる。

737:login:Penguin
09/07/01 21:41:05 RjIEoEza
6月版　君は知っているか？ 2.6.30の変更内容を
URLﾘﾝｸ(www.atmarkit.co.jp)
ファイルシステム周りの追加
　日本発のログ構造化ファイルシステム「NILFS」
　EXOFS
　POHMELFS
　FS-Cache
　relatimeがデフォルトでONに
セキュリティ周りの強化
　TOMOYO
　IMA
ネットワーク周りの強化
　Reliable Datagram Sockets（RDS）
　IEEE 802.11w（wireless management frame protection support）
そのほか、カーネルコアの変更
　カーネルイメージを、従来のGZIPだけでなく、LZMA/BZIP2でも圧縮できるようになりました。LZMAは伸長時間の速さと高圧縮率を兼ね備えており、期待が持てます
　カーネルのzImageがとうとうサポートされなくなりました。bzImageで困りませんからね
　x86の最後のサブアーキテクチャ「Voyager」のサポートコードが削除され、x86 archからサブアーキテクチャ対応コードが削除されました。「これでメンテが簡単になる」と、x86開発者が泣いたとか
　adaptive spinning mutexがマージされました。もはやmutexはロック競合時にスリープするとは限りません

738:login:Penguin
09/07/01 23:52:13 xu0kECu7
>>737
zImage無くなったのはx86だけじゃねえのか？

まあどうでもいいことだが。

739:login:Penguin
09/07/02 14:14:02 /ScnEAS7
>>738
ほかのアーキだと元々 make zImage が存在しないような

740:login:Penguin
09/07/02 14:27:45 /ScnEAS7
ねえ、kernel watch以外にカーネルの情報が読める所ってないの？

741:login:Penguin
09/07/02 14:34:11 7A/mbtL3
>>739
べつに必須の機能じゃないので無い方が多いかもしれんが、
使えるのもある。

さすがにbzImageはx86だけだが。

742:login:Penguin
09/07/02 14:34:12 JUQuwRcW
>>740
つ URLﾘﾝｸ(www.kernelnewbies.org)

743:login:Penguin
09/07/02 18:55:26 0KAGXtNr
フレームバッファを使ってダブルバッファのような目的で複数ページを切り替えて
表示をしたいんですが、ioctlとか使って実現する方法ってありますか？

744:login:Penguin
09/07/12 19:00:16 Hd0P+JHm
>>743
DirectFBあたりは、そうやって実装してるよね

745:login:Penguin
09/07/22 03:26:29 vGwEU6X3
kernel watch の執筆者が、kernel勉強会で講演してるじゃん
YLUG 第97回カーネル読書会 TOMOYO Linuxメインライン化記念勉強会
URLﾘﾝｸ(zoome.jp)

746:login:Penguin
09/07/22 23:07:37 Ihq5K6Dd
米Microsoft、「Hyper-V」LinuxドライバをカーネルコミュニティにGPLv2で提供
URLﾘﾝｸ(sourceforge.jp)

747:login:Penguin
09/07/23 18:18:38 7uKirgZE
ここで一句

カーネルは
テスト無いので
レガシーだ

748:login:Penguin
09/07/23 19:13:55 P+5ig7CA
レガシー【legacy】
(１)遺産。遺物。
(２)コンピューター分野で，旧世代の技術に基づいたハードウエア・ソフトウエアなどの総称。

749:login:Penguin
09/07/23 23:43:17 ndnD86SS
URLﾘﾝｸ(www.tdd-net.jp)

750:login:Penguin
09/07/24 05:29:49 0MjShUNk
ネタがすべってるー

751:login:Penguin
09/07/24 22:00:45 qlwn44yy
>>747
世界がテストベッド。
テスト手順は人間の本能に刻まれている。
１００万個の目玉は１万ページのテスト手順に勝る。

・・・とか信じてそうだ。
実は誰もテストせず数年経過とかあるから怖い。Signed-off-by,
Reviewed-Byに加えて

　Tested-by:<tester-sig>
　Tested-with: <URL-to-testcode>

とか欲しくなるぞ。

752:login:Penguin
09/07/25 12:06:02 4Qinpv4Z
>>751
Tested-by:は昔から使われてるぞ。

753:login:Penguin
09/07/25 12:52:25 3/suj8BZ
>>752
じゃなくて、commitされるものはどれもテストされるべき
って言いたいんじゃない？

754:login:Penguin
09/07/25 15:16:29 wTyfgRHd
テストコードが無いのはレガシーコードだと言いたいのでした。

ただ、ドライバとかはむずかしいのかもとは思った。

755:login:Penguin
09/07/26 13:22:45 FmTSWpi4
Fedora固有の問題なのかもしれないが、kernelの挙動のような気もするので、ここで質問。

/proc/uptimeに入っている値の意味ってkernelのバージョンによって変わりうるのだろうか？
最近、Fedora11 x86-64 (kernelは2.6.29系）をインストールしたPCにおいて、/proc/uptimeの
値は稼働時間（秒）＋謎の値（稼働時間より妙に小さい）になっている感じなのだが、
Feora11を入れるまでは稼働時間（秒）＋アイドル時間（秒）だった。manの説明を見る限り、
以前の挙動の方が正しいように見える。

ちなみに、稼働しているPCの負荷はかなり低くてアイドル時間がほとんどを占めているので、
同じフォーマットの値だとは考えにくい。

何か仕様変更があったのだろうか？

756:login:Penguin
09/07/26 17:47:58 F499QACg
>>755
コードを読む限り、idleを表示しようとしてるな。うちのマシン(mainlineの最新）ではuptimeは以下のようになっており、
妥当な値。

で、最近デカイ修正ないから、regressionに心当たりないなぁ

/proc/uptime
----------------------
2295257.97 1218617.97

CPUを100%つかうプロセスを１分動かすと、２つの値はそれぞれ、どれだけ動く？

757:login:Penguin
09/07/26 18:10:16 F499QACg
>>754
LKML読んでて、テストコードでなんとかなりそうな問題って少ないんだが、具体的にはどうよう状況を想定してる？

例をあげる。
定期的にregressionする問題児機能として、cpu-hotplug, memory-hotplugがあるが、これは明らかに
開発者がテストできないのが問題。
かつ、CPUやメモリを挿抜できるマシンを見たこと無いと何に気をつけないといけないか、普通は一生知る機会がない。
カーネル内に普通にif 文入ってりゃカーネル勉強してれば自然と身につくけど、速度の兼ね合いで巧妙に if文が
入らないようにしてあるケースが多いので、コードを読んでいてもまず理解できん。

個人的な経験でいうと、ユニットテストが有効なのはアプリケーションレイヤだよ。テストってのは自分のもってる仮定が真か
否かを確認する作業なので、よく分からないハードの互換性のための機能とか、よく分からないアプリの互換性のための
機能とかは、テストできない。

それに加えて、性能のために、無理矢理ロックレスにしてる部分ってユニットテストすると、failureするよね。
でも人間は気づかないのでOK理論でまかり通ってる。
この「人間は気づかないはず」ってのはかなり曖昧な根拠なので、すごく予想外のワークロードで破綻したりする。
テスト不足が原因じゃなくて設計時の分析不足が根本なので、テストじゃ品質は上がらない

ちょっと、違う河岸の人の意見が聞きたくなったので、燃料投下ですよ

758:login:Penguin
09/07/26 19:09:21 eLPutGUO
CPUのmockとかメモリのmockを作ってテストを書く
failするロジックを見つけたら必ずテストを追加する

759:login:Penguin
09/07/26 19:10:20 eLPutGUO
とうっかり書いてしまったがそんなへんてこなmockを書くのは極めて難しいな

760:login:Penguin
09/07/26 22:07:20 FmTSWpi4
>>756

stressをインストールして試してみた。CPUがデュアルコアなので各コアの負荷が100％になるようにしてみた。

[root@localhost stress-1.0.0]# uptime; cat /proc/uptime; stress -c 2 -t 60; cat /proc/uptime
21:58:50 up 1 day, 22:31, 2 users, load average: 0.44, 0.35, 0.14
167498.57 166.57
stress: info: [29421] dispatching hogs: 2 cpu, 0 io, 0 vm, 0 hdd
stress: info: [29421] successful run completed in 60s
167558.58 166.57

[root@localhost stress-1.0.0]# uname -r
2.6.29.6-213.fc11.x86_64

稼働時間の方はちゃんと60秒分増えているけれど、2個目の値は変わらず・・・。

761:login:Penguin
09/07/26 22:13:34 YbAk5UrG
ドライバ類って共通レイヤでのユニットテストがしやすそうなイメージあるけどなぁ。
ハードウェアエミュレータがあれば更に良し。

762:login:Penguin
09/07/27 07:26:05 wJYxMPcL
具体的にはどうやってテストするの？
エミュレータなんかかました途端に、それは「エミュレータに対するテスト」
でしかなくなるし、ってかこの世のありとあらゆるデバイスの挙動の
あらゆるケースを実機通り（実機のバグ・不具合含めて）に正確にテスト
できるエミュレータとか、ちょっとありそうにない気がするが。

763:login:Penguin
09/07/28 06:23:34 I6HFN565
>>760
ごめん、CPU100%ぶんまわしたら、当然idle時間は増えんわな。たぶん省電力関係が悪さをしていると思うので

１） cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
の結果を貼っておくれ

２）同じディレクトリの scaling_governorをon_demandから（Fedoraならon_demandなんだよね？）、
performance に変更して１日放置してみて

これで直るなら、ただの表示ミスだから気にする必要はない。

764:login:Penguin
09/07/28 06:37:10 I6HFN565
>>763
起動オプションで、 idle=poll もやってみて。C2/C3 stateに入るときの問題かもしれぬ。

765:login:Penguin
09/07/28 21:24:21 gAPV/qCK
テストってそんなもんな気がするけど???

766:755
09/07/28 22:53:13 3fzUjTnx
>>764
レス感謝。

初めに報告した側のPC(以下PC1）はサーバ運用のため実験しにくいので、同じFedora11 x86_64版をインストールし、
同様の状況になっている別PC（以下PC2）で実験してみた。結果は以下のような感じだった。

[root@localhost ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
acpi-cpufreq
[root@localhost ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand

ちなみにPC1だと
[root@localhost ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
[root@localhost ~]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
powernow-k8

で、PC2でカーネルオプションにidle=pollを追加して起動し、
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor してみた後は

[root@localhost ~]# cat /proc/uptime
1744.18 0.13

という感じで、残念ながら変化無し。

アイドル時間が検出できないこと以外は運用上の障害は特にないので、そのまま運用してもいいんだけれど
やっぱり気持ち悪いなぁ・・・。

767:login:Penguin
09/07/30 00:16:00 +o444z33
ある特徴をもつパケットをIP層でフィルタリングするカーネルモジュール
を書きたいのですが、iptable_filter.cのipt_hook()とかを使って
できますかね？

768:login:Penguin
09/08/04 17:34:45 Ahd4ZMYm
likely() とunlikely() 　について詳しく解説していただけないでしょうか？どうしてこの処理が必要なのでしょうか？

769:login:Penguin
09/08/04 18:05:10 jK3O5/wp
gcc + likely でぐぐれ

770:login:Penguin
09/08/05 19:03:19 NmLViMJY
今時のx86って分岐ヒント・プリフィックスがあるんだね

771:login:Penguin
09/08/05 22:52:05 c9kehUAX
今のgccは分岐prefixは生成しないと思うが。今のCPUの実装でいうと勝手に命令はprefetchされてるんだけど、
ジャンプ命令は飛び先が命令をfetch終わるまで分からない（当たり前だ）、だから、ジャンプしないほうに可能性が
高い処理を入れておくのが賢い。
確率が半々のif文だったら、飛び先を近くにしておくと、ちょっと先fetchでtakenもnot takenもフェッチされるので
お得だけど、確率が90%の時は残り10%はすんげえ遠くに追いやった方がお得。
よってunlikelyで通らないとヒントづけされたブロックは関数の最後の方に寄せられる。likelyはその逆。

772:login:Penguin
09/08/05 23:24:28 6HIRSosI
確か今時のプロセッサの分岐予測は
初見の分岐を見たら、その分岐が手前方向だったら分岐すると予測し
先方向だったら分岐しないと予測すると思ったけど。

理由はもちろん、ループというのがそういう形に作られているため。
(先方向の理由は知らないが、たぶん統計的なものだろう)

で、当然、最適化コンパイラは、
それ(分岐頻度の想定)にあわせた分岐/非分岐のブロック配置をする。

773:login:Penguin
09/08/06 00:06:36 vQt8Mjn6
>>772
実行プロファイルとか取ってるのかと思ったら、あんま賢くないんだね。

774:login:Penguin
09/08/06 13:59:03 7rlUfYmR
>>773
プロファイルとってるけど、数に限りがあるから、テーブルにのってないジャンプについては
typicalなコンパイラのクセからポリシーを決めるんだわさ

775:login:Penguin
09/08/06 22:56:30 aRQrUWVt
>>774
Open64でビルドしたカーネルそんなことしてるように見えないけど

776:login:Penguin
09/08/06 23:12:21 WIwoXzLG
「プロファイルをとっている」のはCPUだぞ？
理解した上で書いてる？
そりゃ、カーネルスレでハードの話題はスレ違いだが、話の流れってものがあるから。

このへんみれば、おおよその技術的なことはわかるんじゃないかね。
Wikipedia項目ﾘﾝｸ

777:login:Penguin
09/08/07 17:00:34 Pvjb3Cze
カーネルのヘッダファイルを見るとenumと全く同じ名前でdefineし直していて単なる無駄に見えるのですがマイナーなコンパイラのための対策か何かなのでしょうか?

778:login:Penguin
09/08/07 17:11:24 tHF5HJWh
具体的に

779:777
09/08/07 17:43:38 Pvjb3Cze
>>778
僕にだよね...
例えば、linux/rtnetlin.hだと↓

enum {
RTM_BASE = 16,
#define RTM_BASE RTM_BASE

RTM_NEWLINK = 16,
#define RTM_NEWLINK RTM_NEWLINK

780:login:Penguin
09/08/07 18:13:53 tHF5HJWh
>>779
型チェックが欲しいときと要らん時があるからだろ。

781:777
09/08/07 18:45:03 Pvjb3Cze
>>780
プリプロセッサ通ったらやっぱりenumだと思うんだけど...?

782:login:Penguin
09/08/07 18:45:15 ZCbtwiUW
型チェックはプリプロセッサではやらないと思うんだけど。

783:login:Penguin
09/08/07 19:01:22 Pvjb3Cze
だから、
わざわざenumとdefineと定義してもプリプロセッサを通ったらenumだけになっちゃう
で、コンパイラではenumの定義しか見えないんだから型チェックがしたい/したくないとか制御できてないように思うんですが...

784:login:Penguin
09/08/07 19:08:38 KtOPT9+5
例えばglibcのstdio.hの中に以下のような一節がある

/* Standard streams. */
extern struct _IO_FILE *stdin; /* Standard input stream. */
extern struct _IO_FILE *stdout; /* Standard output stream. */
extern struct _IO_FILE *stderr; /* Standard error output stream. */
#ifdef __STDC__
/* C89/C99 say they're macros. Make them happy. */
#define stdin stdin
#define stdout stdout
#define stderr stderr
#endif

>>779 もこの手の要請のせいではないかと予想

785:login:Penguin
09/08/07 19:15:42 tHF5HJWh
>>783
netdev辺りに remove unneeded definition とか言ってパッチ投げると
なぜそうなってるか解説してもらえるんじゃないかな。

786:login:Penguin
09/08/07 19:22:17 ZCbtwiUW
>>783
ごめん、>>782は>>780へのレス。というか>>781を読まずに書いた。

787:login:Penguin
09/08/07 20:01:34 rGcT3Hcr
#define stdin stdin
しておけばプリプロセッサがstdinを消しちゃうこともないし
#ifdef stdin
でもtrueになるし
ってだけの話じゃないの？

788:login:Penguin
09/08/07 22:53:31 Zmpep1HC
Amazon EC2 の日々の利用料金を確認するため
日毎のI/Oリクエスト合計数を出したいんですが
なにかいい方法ないでしょうか？

iostat の tps ってシステムが稼動始めてからの合計？
それだと日毎に、ってのは難しいですよね

789:login:Penguin
09/08/08 01:12:06 fEJHlBnC
>>777
デバッグのときにシンボル補完してくれるからかも？＞enum
マクロもビルドオプション付ければ可能ではあるんだけど、カーネルが
超巨大化するので。

790:777
09/08/08 12:11:41 O2AsxnLe
みなさんありがとうございました。
>>787のifdefしたいはなんとなく納得できます。

791:login:Penguin
09/08/10 22:33:28 abkAQLZt
最近のLinuxの
Memory Mapped Fileって

メモリにWriteしてSyncすると
pbufferが走るの？

792:login:Penguin
09/08/10 23:02:05 eejzbTvy
っカーネルソース

793:login:Penguin
09/08/11 20:07:58 2WktrRtv
@vger.kernel.org 系の ML 止まってる？

794:login:Penguin
09/08/11 20:59:05 2WktrRtv
流れ出したみたい

795:login:Penguin
09/08/14 22:33:29 imrAHybe
intelチップセットのノートPC使ってるけど

　DRMを有効　→　X起動でフリーズ
　DRMを無効　→　X激遅で使い物にならず

うんざりしてきた

796:login:Penguin
09/08/14 22:37:26 rN7Fq7S1
nVidia一択がJK

797:login:Penguin
09/08/14 22:43:27 VAslznzA
Intel 安定
NVIDIA 速い
ATi Windows専用

798:login:Penguin
09/08/14 23:12:57 XR99CTCn
9月10日に
RV870はLinuxに対応しないって明言するらしい

799:login:Penguin
09/08/17 11:35:22 /cA/EyFg
2.6.29→2.6.30でUSBまわりって大きく変わった？
まったく同じconfigで作ってもfriioがUSBエラーを吐きまくるようになったんだが…

800:login:Penguin
09/08/17 11:41:28 ohk2Aoag
linus-treeにマージされてないと大変だね。
カーネルのABIが変わっても自分で調べて直さなきゃならないし、
作者の興味が無くなったらそこで終了。

801:login:Penguin
09/08/17 12:22:17 B4Bxz+2u
マージしたらいいのに。ドライバならGregはすぐマージしてくれるよ

802:login:Penguin
09/08/17 12:25:45 uz6wkSgr
　ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　　　　 ( : : : : : : : : : : : : : : ｀ゝ　 /
　　マ　　r::/: /: : | : : : : : : : : ::＼ /
　　｜　//: /: : : |: : | |: : |: _: : : :ヽ
　　ジ　 {/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　で　／ r:oヽ`　　　/.:oヽヽ: :|: | :|
　　　　{　{o:::::::}　　　　{:::::0　}/: :|N
　　っ　 |　ヾ:::ソ　　　　ヾ:::ｿ /|: : |
　！？ヽ::::ー-..　／ヽ　..ー-::: ヽ::|　r--ッ
-tヽ／´|｀::::::::::;／　　 `､ ::::::::::: /: i　}　＞
::∧: : :|: |J　　＼　　／　　／::i: | /＿ゝ
. ＼ヾ: |::|｀ - ,, ___｀-´_ ,, - ´|: : :|:::|
　　ヽ: |::|＼　　　￣/ /|　　|: : :|: |

803:login:Penguin
09/08/17 13:29:25 IIDjTJ7I
>>799
そうおもったんなら、なぜChangeLogを見ようとしないのだ？

804:login:Penguin
09/08/17 13:36:32 N7HpcAG+
>>800-801
そういうのはマージされた所で変わらん。
名前変えたぜくらいならついでに直してもらえるが、
微妙に仕様変わったりする場合は放置される。

805:login:Penguin
09/08/17 13:58:45 Pk6+wyDO
>>802
うけたw

806:login:Penguin
09/08/17 14:03:50 F9Hxs/Y9
>>802
　ｲ｀ﾍ
　/: :| ヽ
/ : :/　　ヽ　＿＿＿　　　_,,,:. .-: :´彡ﾌ
_ノ＼＿∠: : : : : : : : :｀: :-: :,:_:／彡　/
　　ま　　( : : : : : : : : : : : : : : ｀ゝ　 /
　　　　　r::/: /: : | : : : : : : : : ::＼ /
　　ふ　//: /: : : |: : | |: : |: _: : : :ヽ
　　ぃ　{/ 7|｀＼/i: /|:|／|´: : : : :|ヽ
　　　　〉 ,‐-‐､｀|7　|| |_::|,_|: : :|:::|: |
　　ふ　／ r:oヽ`　　　/.: oヽヽ:|: | :|
　　ぇ　{　{o:::::::}　　　　{:::::::0 ヽ: :|N
　　っ　 |　ヾ:::ソ　　　　ヾ:::::::ンゝ|_ノ´￣｀¨ヽ
　！？ヽ::::TT..　ｨ―--ァT´弋_,.,ィー-
-tヽ／´|｀::::| |::;／　　　／:| |:::: ／:i つ＼__
::∧: : :|: |J　| | ＼　　　／　| |／::i: | 二ン
. ＼ヾ: |::|｀ - ,, ___￣￣_ ,, -´|: : :|:::|
　　ヽ: |::|＼　　　￣/ /|　　|: : :|: |
　　　　_,,,ヽ_ヘ_,,_ﾉ＾ﾚ,,_....

807:login:Penguin
09/08/17 19:18:31 b3LzJIdw
すごい亀で申し訳ないが、>>755ってこれじゃねぇの？

URLﾘﾝｸ(lkml.org)
URLﾘﾝｸ(lkml.org)

808:755
09/08/17 23:29:09 BdjlVxHY
>>807
当たりっぽい。
ソースを見た感じだと、64bitで扱わなきゃならない箇所を32bitで扱ってしまっているのか・・・。
LKMLに上がっているということは、いずれパッチが取り込まれるのかな？
アイドル時間が分からない以外の実害はないんで、もうしばらく待ってみる。

809:login:Penguin
09/08/18 00:09:01 AEIuMqWU
カーネルコンパイルするときの、LD とかCC の意味を教えてください。

810:login:Penguin
09/08/18 00:46:01 T2Dm2Hjr
あんまり深く考えたことないけど、普通に考えて

CC: コンパイル
LD: リンク

じゃねぇの？メッセージ的にもそれっぽいし

811:login:Penguin
09/08/18 00:50:49 t149Kxcg
>>810
あたり

812:login:Penguin
09/08/19 21:41:26 Tho/5L2s
IPCセマフォとPOSIXセマフォを比較すると

IPC配列が複数個で遅い
POSIXは1個だから軽量みたいな説明を見るのですが

具体的にデータ構造ではどれのことを指しているのでしょうか？

813:login:Penguin
09/08/19 21:58:19 oqH6+Tca
>>812
glibcのnptl以下のsem_* をみれ。そもそも競合がないかぎり xchg 命令一発で終わっており、
カーネルの中にすら入らないから
逆にPIC セマフォをlocklessにしたり、ユーザランドだけでごにょごにょする方法は未だ見つかって
いないのではないかな。

814:login:Penguin
09/08/20 12:43:42 IuJt3Yqf
Debianのdepパッケージについて質問です。
公式サイトから落とせるarm用パッケージの共有ライブラリが、どんなconfigureオプションで
コンパイルされているのか調べる方法ってありますか？
gccだとgcc -vってやった時にコンパイル時のconfigureオプションが表示されますが、あんな
感じで調べる方法があれば教えてください。

815:814
09/08/20 12:45:30 IuJt3Yqf
ごめんなさい、スレを間違えました。

816:login:Penguin
09/08/20 20:30:22 +k9Nz7s4
早くLinuxのカーネルがFreeBSDのカーネルよりパフォーマンスよくならないかなー・・・

817:login:Penguin
09/08/20 21:12:06 gFmbm5B9
>>816
まだそんなに差があるの?

818:login:Penguin
09/08/20 21:24:31 +k9Nz7s4
>>817
スループットの計測グラフみたら2.6.30とFreeBSD7.2の間に結構差があった

819:login:Penguin
09/08/20 23:55:01 XTDFR6e5
>>818
そうなんだ。
URLﾘﾝｸ(d.hatena.ne.jp) の
NetBSD 5.0だかのグラフで、Linux(Fedora Core 10)の方がFreeBSDよりいいのかなって思ってた。

820:login:Penguin
09/08/21 00:07:50 YkMVscqX
誰がベンチマークを計測したかによって変わるしな。
ベンチマークを公開するにはちゃんと意図があるのだよ。

嘘には３種類あって
・良い嘘
・悪い嘘
・ベンチマーク
と言われている。

821: ◆Zsh/ladOX.
09/08/21 00:53:05 LinlgJyn
そんなに凄いならスパコンとかに顔を出してもいい感じだが。>>BSD

ってカーネル関係ないかw

822:login:Penguin
09/08/21 01:42:13 T7hb8yiR
スケーラビリティが要る場面ではLinuxが強いだろ。
マン・パワーを必要とする膨大な作業があるから、大企業が
よってたかって人手を投入しているLinuxのほうが上なのが普通なはず。

823:login:Penguin
09/08/21 02:39:53 p2qtAUKk
>>818
SELinux使っているってオチとか?

824:login:Penguin
09/08/21 06:45:00 pxACKAQd
>>819
NetBSDすっげえな

825:login:Penguin
09/08/21 10:18:05 De+1kbfp
>>822
残念ながら、現状のlinuxカーネルのスケーラビリティは他のOSに比べたら悪くて当然な出来。
まだまだspinlock多すぎ。

826:login:Penguin
09/08/21 10:25:05 taRwReOf
プログラムとか全くできない素人の素朴な疑問なんだけど
Linuxカーネルって、みんな寄ってたかってこんだけいじくりまくってるのに
どうしてパフォーマンスが上がらないの？

827:login:Penguin
09/08/21 10:35:30 b9Y8OXWv
>>826
上がらないって、どうやって計ったの?

828:login:Penguin
09/08/21 10:42:07 taRwReOf
計ったなんて書いてないけど？

829:login:Penguin
09/08/21 10:44:05 b9Y8OXWv
え、計りもせずに「上がらない」なんて言ってんの!?

830:login:Penguin
09/08/21 10:45:31 p2qtAUKk
>>826
BKLが残っている
カーネルスレッド多すぎ: URLﾘﾝｸ(lkml.org)
adaptive lockが採用されてないって聞いたことある
SIMDがあまり使われていない(レジスタ退避との兼ね合いで避けられているが、高速化できる場所はもっとあると思う)

ってことでパフォーマンス上がる余地はあるけど、他のカーネルと比べてどうかは知らない。

831:login:Penguin
09/08/21 10:49:30 HWzVO6eL
カーネルスレッド多すぎの件は、何年か前にsgiの連中が
4096CPUマシンで動かしたときに何とかならんもんか
といってたけど、やっとパンピーのマシンに多コアマシンが
降りてきたから真面目に取り組みはじめたね。

832:login:Penguin
09/08/21 10:54:04 MlJa3Ii9
カーネルスレッドならWindowsだってかなりあるじゃん
スケジューラの問題じゃないの？

833:login:Penguin
09/08/21 11:01:43 6GhqxsGw
>>830
SIMDはレジスタ退避のコストを考えるとほとんど期待出来ないと思ふ。

やっぱりそこら中に散らばってるspin lockのCPU無駄使いが諸悪の根源だと思うでよ。

834:login:Penguin
09/08/21 11:06:27 taRwReOf
>>829
スレの流れからそういう話だったじゃん。
それとも自分で確かめた結果以外は話にも出すなってか？
俺ルール？

>>830
どうしてそうなのかってとこが気になるんだけど、
昔から色々な選択肢を方々に提供してきただけに
ある機能がレガシーになってもなかなか切れない、
構造も変えにくいってことかな…？
ちなみにadaptive lockは2.6.30で載ったっぽい？

835:login:Penguin
09/08/21 11:27:39 p2qtAUKk
>>834
個人的にはカーネルのプロファイリングの手法がしょぼかったせいじゃないかなと思っている。
最近のプロファイラの進化によってパフォーマンスは上げやすくなったんじゃないかなぁ。

836:login:Penguin
09/08/21 11:31:02 MlJa3Ii9
というかハッカーならロックなんて使わずにカーネル作れよ
スピンロックなんて使っておいて何がハッカーだよ（笑）

837:login:Penguin
09/08/21 11:32:58 HWzVO6eL
mutex: implement adaptive spinning
URLﾘﾝｸ(git.kernel.org)

838:login:Penguin
09/08/21 11:42:48 HWzVO6eL
>>831 のソースが見つかった
URLﾘﾝｸ(lwn.net)

839:login:Penguin
09/08/21 11:53:26 p2qtAUKk
>>836
lockless/wait-freeは最近の流行だねぇ。lock自体がBKLと同じ扱いになる日が来るかもな。

840:login:Penguin
09/08/21 12:07:05 bWwhod0w
Linuxの設計やパフォーマンスはそんなに悪くないよ。
ただ、BSD(のネットワーク周りなど)の初期設計がとても良いので、
そこが効くベンチマークを取ると差が出るだけ。

841:login:Penguin
09/08/21 12:12:48 pxACKAQd
とりあえずBSDに比べればめちゃくちゃ人多いわけだから今後に期待

842:login:Penguin
09/08/21 12:52:01 6GhqxsGw
人が多けりゃどうにかなる問題でも無いと思うぞ。

自動テストでプロファイル取って、遅くなる修正入れたら
ボコボコにされるとかやれば何とかなるかもしれんが。

そんなことをgccがやってるとか何とか聞いたような気がする。

843:login:Penguin
09/08/21 12:55:48 vx/cVYTm
>>834 前半
別人だが >819 の主旨はNetBSDのバージョン間の比較だし
「上がらない」はLinuxのバージョン間の比較と解釈できる表現だし
それでいて今のスレの流れにベンチマーク結果があるのは >819 の
Fedora Core 10 ひとつだけだから「ソースは？」とつっこまれたんだろ。

>827 のつっこみ方もどうかと思うがそんなに敵意をむき出すことは無いだろ。

844:login:Penguin
09/08/21 16:39:20 5M/wknFG
>>840
ネットワーク周りはLinuxのほうがパフォーマンス出てるって聞いたけどなー

数年前の話だから今は違うんか?

845:login:Penguin
09/08/21 19:36:35 WaG9vPdi
>>844
場合による。10Gイーサとか最新の環境ならLinux一択。Linux世代が入手できない古代のハードなら絶対BSD。
それ以外はドライバの出来も効くのでケースバイケース。

846:login:Penguin
09/08/21 19:37:55 WaG9vPdi
カーネルスレッドが多すぎ問題はJensが対応を開始したよ。ざっと見た感じ結構有望そう

847:login:Penguin
09/08/21 19:39:19 WaG9vPdi
BKLは性能に関係有るところにはもう残ってないので気にしなくてよいと思われ

848:login:Penguin
09/08/21 19:43:52 IuT2OPFN
ReiserFSからもいなくなったの？

849:login:Penguin
09/08/21 20:13:46 WaG9vPdi
mainlineにもう入ったかは忘れたが、Fredricがなくしたはず

850:login:Penguin
09/08/21 21:51:17 00xOIOY7
SystemVとPOSIXのソースをおいかけてたら
気がついたらこんな時間になってたけど
以下の理解で正しいの？

SystemVセマフォ
userspace->sem_op->syscall->kernel->kernel lock

POSIXセマフォ
userspace->sem->glibc->syscall->kernel->kernel lock
競合無いとき
userspace->sem->glibc

851:login:Penguin
09/08/21 23:29:52 ATg1NEMY
最近のカーネルでirqbalance使う意味ってある？
使わなくてもいい感じに負荷分散されてる様に見えるんだけど…

852:login:Penguin
09/08/22 00:03:06 LGqzvHPp
うちで何もしていないやつはエラく偏る@Athlon64X2
17: 33 24973 IO-APIC-fasteoi firewire_ohci
18: 485064 140728827 IO-APIC-fasteoi eth1
20: 54911 19292568 IO-APIC-fasteoi sata_via
入れればそれなりにならされるので無意味じゃないだろう。

俺は気にしていないので何もしていないが。

853:login:Penguin
09/08/22 00:15:59 1NbfsqaS
偏った方が、逆にキャッシュの使用効率がいいと思うんだけど。

854:login:Penguin
09/08/22 09:47:18 iygx6FPk
kernel-2.6.30.5 です
不要なデバイスドライバーを削りたくて、とりあえず手始めにネットワークカードを選択したいのですが
機種 NEC Express5800／110Ge
LAN Intel 82566DM-2 Gigabit
これに必要なデバイスドライバーはどれを選択したらいいのでしょうか？
Device Drivers --->[*] Network device support --->？

855:login:Penguin
09/08/22 10:03:15 yjOdojRy
ところで起動中の
starting httpd　　　　　　　　　[OK]
とかの書式とか色とかってどこで変更可能？

856:login:Penguin
09/08/22 11:07:05 Qg2YY+77
>>854
ググったら、e1000e がドライバらしいから、その後

　--> Ethernet (1000Mbit) --> Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support

2.6.31-rc7 での選択だけど、多分変わらない

>>855
カーネル関係なくないか？
何使ってるかしらんが起動スクリプト(/etc/rc.d/rc)と、
それから読み込まれるいろんなファイルを見ていけばいいんじゃない？

857:login:Penguin
09/08/22 11:13:51 RpQH+zaA
>>854
ドライバはたいていモジュールでコンパイルされるので、リソース食わないよ?
組み込みの人?

858:login:Penguin
09/08/22 11:19:30 iygx6FPk
>>356
ありがとうございます、どのような文言で検索されましたか？
よろしかったら教えてください
とりあえずNetwork device support 配下の
--> Ethernet (1000Mbit) --> Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support
これだけに* を入れて今コンパイルしています。

859:login:Penguin
09/08/22 11:25:37 Qg2YY+77
>>858
多分、俺の事だと思うので…

「Express5800／110Ge」でググっただけ。で、
　URLﾘﾝｸ(wiki.nothing.sh)
に書いてあった。

ただ、>>857も言ってるけどわざわざドライバ切ることもないとも思う(サーバマシンだし)
まぁビルド時間節約はできるけど

860:login:Penguin
09/08/22 11:33:36 iygx6FPk
>>859 さん
>>857 さん
ありがとうございます。

861:login:Penguin
09/08/22 13:32:21 Cj3XfUQp
>>853
キャッシュのaffinityを重視するかCPUのロードバランスを重視するかって話だけど、
大抵の場合はaffinity重視で行ったほうが全体の性能はあがるよね。

862:login:Penguin
09/08/22 14:56:31 kbUxBrOu
>>861
普通のプロセスに関してはそういう作りになってるんだし、
一般論を話しててもしょうがないかと。
個々のケースについての具体的な数字が無いと。

863:login:Penguin
09/08/22 17:56:26 Cj3XfUQp
>>862
普通のプロセスの話じゃなくて、割り込み～ksoftirqdまわりの話なんだけど…

864:login:Penguin
09/08/23 22:35:17 DukYj/4T
日々の給料に数万円の現金をそのまま上乗せ
ＩＴ廃品回収ビジネス

URLﾘﾝｸ(2ch.zz.tc)
（情報料６万５０００円）