☆Linux カーネルの仕組みを勉強するスレ☆
■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin
01/10/02 17:44ID:38KkZsUQカーネル全般について語り合うスレッドです。
0630名無しさん＠Ｅｍａｃｓ
03/03/28 23:27ID:tgiw/vfZうん。つまり、カーネルとドライバが違う権限で動いているOSでは避けられる。
0631名無しさん＠Ｅｍａｃｓ
03/03/28 23:28ID:tgiw/vfZ0632山崎渉
03/04/17 12:11ID:PWISM87M0633山崎渉
03/04/20 06:09ID:X64WTq1+（ ＾＾ ）＜ ぬるぽ（＾＾）
0634login:Penguin
03/05/04 17:20ID:ide68tWq0635login:Penguin
03/05/06 20:57ID:/f1wWtEtにLinuxカーネルについての解析資料が移動したらしい。
0636login:Penguin
03/05/14 17:38ID:+1wC02Dwあるいはgccでガチガチ最適化カマしたやつとか。
0637ヽ(´ー｀)ノ
03/05/15 09:38ID:MQgHohK4Intelコンパイラは知らないけど、gcc で最適化するのなら自分でリビルドすればいいのでは？
イマドキのマシンなら30分くらいで終わるっしょ。
// 俺のじゃ丸半日掛かるけどなー
0638login:Penguin
03/05/15 20:15ID:tl6lLPOqそんな貴方にGentooLinux
（iccも使える、、と思うけど、そっちはよーしらん）
0639login:Penguin
03/05/15 21:50ID:fOOiJy16なぜCではなくC++？ なのかは置いておいて、
今のバージョンのintel C compilerだとLinux kernelがコンパイルできんので無理。
というか羊頭狗肉になっちまう。
次期バージョンでkernelがコンパイルできるようになったら
それを売りにするディストロも出てくるかもな。
gcc最適済ディストリは今は無き？stampede Linuxがやってたが、
gentooとかなら自分でできるだろ。
0640山崎渉
03/05/22 02:18ID:VfjbtMwi0641login:Penguin
03/05/24 02:05ID:pFXNmjMbソースのコメントに「これらのオフセットはハードコードされている．注意して扱うように．」みたいなことが書いてあるのですが．
0642login:Penguin
03/05/24 02:12ID:B4Q+JvDP忠告に従ったほうがいいかも。
どっかの地雷をふむかもしれないよ。（ｗ
0643login:Penguin
03/05/24 02:46ID:Ac66WbG3archによる。
アセンブラのコードで直接見ていることがある。
Cの方はオフセットがずれて困るところはないはず。
0644login:Penguin
03/05/24 03:01ID:B4Q+JvDPいぁ、ちょと見てみたんだが。
Cでtask_struct構造体ポインタに対してaddする個所があった。（ちなみにi386ね）
grepしてみたけど修正してできない量ではない。
けど、結構気をつけないといけないかも。
0645初めて
03/05/24 11:12ID:3ITeRmp+何度やっても
Uncompressing ... Ok,booting the kernel.
で止まってしまいます。
理由がわかりません。
なにかチェックする項目を飛ばしているのでしょうか？
2.4.20で起動するconfigからmake oldconfigで再度.configを作っているつもりなのですが。
これだけでの情報では原因を推測することは無理でしょうか？
OSはRedhat9.0で、再構築したいカーネルは2.5.69です。
どなたかアドバイスを頂けないでしょうか？
よろしくお願いします。
0646643
03/05/24 11:21ID:Ac66WbG3そんな所あったっけ？
しばらくi386依存部分は触っていないから、記憶が薄れつつあるなー。
>>645
おとなしく2.4.20を使う。
2.5.69はハードウエア構成によっては、そういう問題がおきます。
0647login:Penguin
03/05/24 14:44ID:im3d3bk6問題が起きたらデバッグしてください。2.5シリーズというのはそのためのものです。
0648644
03/05/24 15:13ID:PMIRyT6Tcopy_thread関数での以下の個所
int copy_thread(int nr, unsigned long clone_flags, unsigned long esp,
unsigned long unused,
struct task_struct * p, struct pt_regs * regs)
{
struct pt_regs * childregs;
childregs = ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ここ
0649644
03/05/24 15:31ID:PMIRyT6T>2.4.20で起動するconfigからmake oldconfigで再度.configを作っているつもりなのですが。
>これだけでの情報では原因を推測することは無理でしょうか？
>OSはRedhat9.0で、再構築したいカーネルは2.5.69です。
make oldconfigではなくmake mrproperからmakeしてみては？
0652645
03/05/24 19:30ID:3ITeRmp+make oldconfig
というのは、
そのフォルダにある、.configをもとにして足りない所を補い,新たな.configを
作成するというのであっているのでしょうか？
そのとき作成にしようした.configはoldとかにリネームして。
よろしくお願いします。
0653login:Penguin
03/05/24 19:43ID:b1IFVpVtlinux/scripts/Configure
読みなされ。
足りないところは聞いて来るはずだが。
>>645 の症状ってカーネル2.2の時の経験だと、
以降のboot messageがserialに出力されていた事があるけど、
これって2.4の話？ 2.5の話？
0654643
03/05/24 20:17ID:Ac66WbG3じゃなくて、お子さまプロセスのカーネルスタックの位置を計算しとるのですよ。
んで、計算した所に親の情報をコピーすると。
>>653
2.5はKconfigになってもーたので、scripts/Kconfig/confです。
挙動は変わらんが。
シリアルコンソールは、起動時に"console=〜"渡さないと有効にならないと思ったが。
0655644
03/05/24 21:10ID:PMIRyT6T((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
これって親のtask_structからレジスタ情報を取得してるってこと？
で、
struct_cpy(childregs, regs);
親プロセスの現レジスタを子スレッドのレジスタにコピーして、
childregs->eax = 0;
childregs->esp = esp;
子スレッドのスタックを初期化して、
p->thread.esp = (unsigned long) childregs;
p->thread.esp0 = (unsigned long) (childregs+1);
親のスレッドスタックに生成するスレッドとその次のスレッドを設定して、
p->thread.eip = (unsigned long) ret_from_fork;
親スレッドの実行開始ポインタにcloneの戻り値を設定して、
savesegment(fs,p->thread.fs);
savesegment(gs,p->thread.gs);
親スレッドのセグメントレジスタを子スレッドに設定して、
unlazy_fpu(current);
struct_cpy(&p->thread.i387, ¤t->thread.i387);
ここらがよくわからんが。
ってこと？
0656645
03/05/25 00:25ID:XrZOXyc/0657643
03/05/25 00:59ID:Ix3J6K8u>>655
> ((struct pt_regs *) (THREAD_SIZE + (unsigned long) p)) - 1;
自分のスタックのアドレスを計算してるのです。
task_structのアドレス＝カーネルスタックの先頭アドレスなので、
そこにサイズを足してカーネルスタックの最終アドレスを求めて、
これからセットするデータの分だけ手前にもどす。
> struct_cpy(childregs, regs);
正解。
> childregs->eax = 0;
> childregs->esp = esp;
> p->thread.esp = (unsigned long) childregs;
> p->thread.esp0 = (unsigned long) (childregs+1);
大体正解。cloneの戻り値はeax
> p->thread.eip = (unsigned long) ret_from_fork;
自分に制御が回ってきた時、ret_from_forkから実行開始。
> savesegment(fs,p->thread.fs);
> savesegment(gs,p->thread.gs);
正解。
> unlazy_fpu(current);
> struct_cpy(&p->thread.i387, ¤t->thread.i387);
コプロのレジスタをコピーしているのです。
0658641
03/05/26 12:16ID:L9Tg8SeEありがとうございました．
皆さん凄いっすね．
0659login:Penguin
03/05/26 22:52ID:IXHBibv2CC kernel/timer.o
CC kernel/user.o
みたいな感じでなかなか新鮮
0660_
03/05/26 23:12ID:5mPv2JRl0661bloom
03/05/26 23:13ID:8OPOVfmH0662login:Penguin
03/05/27 00:44ID:Tx2/4y2mそのへんもだいぶ変わったからねえ…
make depなくなったし。Makefileの書き方も変わったし。
まあ、そのへんはどうでもいいんだけど、Kconfigの書き方が未だによくわかりません。
昔のドキュメント位詳しい物を早く書いてくれ。
0663login:Penguin
03/05/28 02:46ID:ZVfjfeIZうまく動作しません．
0664login:Penguin
03/05/28 02:55ID:ZVfjfeIZ以下がソースです．
#define MODULE
#define __KERNEL__
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/types.h>
#include <sys/syscall.h>
MODULE_LICENSE("GPL");
int (*real_setuid)(uid_t);
extern void *sys_call_table[];
int new_setuid(uid_t uid){
printk("system call was intercepted(setuid).\n");
return (*real_setuid)(uid);
}
int init_module(){
real_setuid = sys_call_table[SYS_setuid];
sys_call_table[SYS_setuid] = (void *)new_setuid;
printk("system call intercept(setuid) attached.\n");
return 0;
}
int cleanup_module(){
sys_call_table[SYS_setuid] = (void *)real_setuid;
printk("system call intercept(setuid) detached.\n");
return 0;
}
このモジュールをinsmodで組み込んでsetuidを実行する簡単なプログラムを実行してみましたところ，/var/log/messagesには意図した文字列が出力されません．
自分でもがいてみましたが，原因が分かりませんでした．どなたかご教授お願いします．
0665山崎渉
03/05/28 16:40ID:4u9ffZfOﾋﾟｭ.ｰ ( ＾＾ ） ＜これからも僕を応援して下さいね（＾＾）。
＝〔~∪￣￣〕
＝ ◎――◎ 山崎渉
0666login:Penguin
03/05/28 20:52ID:c/4bMbQpモジュールから上書きしていいものかどうか知らないけど、
int init_module(){
real_setuid = sys_call_table[SYS_setuid];
sys_call_table[SYS_setuid] = (void *)new_setuid;
printk("sys_call_table=%p,sys_setuid=%p,new_setuid=%p\n"
,sys_call_table,sys_call_table[SYS_setuid],new_setuid);
printk("system call intercept(setuid) attached.\n");
return 0;
}
みたいにして、予定通り書き変わっているか確認するしか無いでしょう。
0667login:Penguin
03/05/29 06:56ID:4nmgTop10668_
03/05/29 07:04ID:yrkPpXVA0669bloom
03/05/29 07:13ID:pdJrRzE30670login:Penguin
03/05/30 22:16ID:fuM2ZNep0671login:Penguin
03/05/30 23:09ID:XCgqHAqg0672直リン
03/05/30 23:13ID:t6UbAlau0673login:Penguin
03/05/31 03:10ID:DvCwdjkRi386系はMMUで実行権限の可、不可ってできなかったように
思えたけど（実際には読み込み権限と書き込み権限があって、読み込み権限＝実行権限）
実際、OpenBSDはどういう実装なんでしょうかね？
0674login:Penguin
03/05/31 10:26ID:pCrUKetPi386は実装中じゃなかったっけ？
思い付くのは、P落としておいて例外処理でごにょごにょ…って激しく遅くなりそう。
0675login:Penguin
03/06/02 04:39ID:CgaTSeAjありがとうございます．
やっぱりちゃんとアドレス自体は書き換えているようです．
で，他のシステムコールは正常にフックしています．setuidだけ（全てを確かめたわけではありませんが）が変なようです．
ライブラリを使わずに直接例外でsetuidを発行するとフックできました．
glibcのソースを見てみましたが妙なところは見あたりません．フツーのスタブのようです．
他のユーザID変更のシステムコールを使って発行しているのかな，とか思ったりします．
いずれ確かめます．
0676login:Penguin
03/06/02 15:53ID:Sji9M+OKRT signalを100%使い切るという結果がでてます。。。
loglotateでこーなるのか？？？
RT signalってなに？？
いろいろ探してみたのですが、なんでかわかりません。。。
だれかおしえてください。すみません。おねがいします。
0677login:Penguin
03/06/02 15:58ID:mduTnBfC0678login:Penguin
03/06/02 16:10ID:Sji9M+OKRT signal = リアルタイムシグナル と想定、
http://www.mmjp.or.jp/sunami/linux/kernel/ によると、
なんらか(ソフトウェア、ハードウェア)のシグナルの割り込み処理が
いっぱいいっぱい発生しているものと理解。
loglotateなどディスクをすごく使いそうな処理でこういう自体が
発生しているものと予想。
カーネルにとってRT signalのリミット100%を使い切るような処理
は日常茶飯事であって別に心配するこたぁないのか。
なんらかの対策をするべきことなのか、知りたいのです。
/proc/sys/kernel/rtsig-max が現在1024ですが、使い切っている
から安易に調整するべきものなのか、それとも運用を変えるべきなのか。。。
0679login:Penguin
03/06/02 17:20ID:tEGqhx7Sはずせば？
俺、リアルタイムで画像を記録するサーバ書いたんだが、slocateとかの
おかげで取りこぼしがでたからスクリプトはずしたよ。
0680login:Penguin
03/06/12 03:53ID:+ZjTB6j3試したのですが，唯一execveをフックするようにした時のみアプリケーションの起動で
segmentaion faultが起きます．アプリケーションが何も起動できません．
カーネルの中で起きているのでgdbが使えません．
皆さんはカーネルデバッグはどうしているのですか？
やっぱりUML+gdbとかですか？
それとカーネルモジュールのデバッグもUMLとかでやれるのでしょうか？
0681login:Penguin
03/06/12 08:32ID:9LpMpr/G0682login:Penguin
03/06/12 10:26ID:uPg3Erb9あの方法を使ったら、そうなるでしょうねえ。
(v)fork/clone/execveはアセンブラ使わないと無理でしょう。
デバッグは大体printkで。
kdbを使ってみたいなーと思う事もあるけど
2.5に対応していないので、使えない。
0683login:Penguin
03/06/12 11:20ID:+ZjTB6j3kgdbは確かデバッグを行う別のマシン（OS）が必要ですよね？
家は一台しかlinuxにさけるPCがないので，仮想マシンにするならUMLを使いたいです．
>>682
>あの方法を使ったら、そうなるでしょうねえ。
>(v)fork/clone/execveはアセンブラ使わないと無理でしょう。
なぜそうなるのでしょうか？
また，アセンブラでどのようにすれば実現できるのでしょうか？
というか，特定のシステムコールのフックは通常は
モジュールを使わずに直接sys_*の中を変更すべきなんでしょうが・・
0684682
03/06/12 16:28ID:uPg3Erb9kgdbなら、i386-elfを読めるgdbが動けばlinuxでなくても使えるはず。
んで本題。
arch/i386/kernel/process.cを読めばわかりますが、
system_callの所で作ったスタックフレームの構造に依存しているので、
スタックの状態を維持したまま呼んであげないといけません。
アセンブラなら、
call 自前の処理
mov 元のアドレス,%%eax
jmp %%eax
てなかんじで呼べば問題無いはず。
(i386のアセンブラは最近書いていないので参考程度に)
もう少し汎用的な書き方にならないかなーと思いますが、
CPUコンテキストが絡む話なので難しそうだな。
0685login:Penguin
03/06/13 02:15ID:Ntzc1lmuLinux2.5.64のソースにmachとかいうディレクトリがあるのだが、あれは一体なんなんだろうか。
ついでにもう一つ訊きたいのだがmach-voyagerとかいうのもあるのだが、あれは一体なんなんだ？
教えて君ですまん。
0686login:Penguin
03/06/13 08:39ID:EXw4iEhumachine architecture じゃないの？ m68kのmacとかsun3みたいに。
voyagerは確か昔のia32の超SMPマシン(といっても32くらい)、
って、linux/Documentation/voyager.txt があるやん。
0687685
03/06/15 16:25ID:TNnPLPxBThink!ミスター。あんた最高だよ。
0688login:Daemon
03/06/15 18:47ID:wufUnmIS＊BSDのカーネルについてかかれたものはないですか？
0689login:Penguin
03/06/15 18:48ID:vowloLzR0690login:Daemon
03/06/15 18:51ID:wufUnmIS0691login:Penguin
03/06/15 23:09ID:x0Igtqsi悪魔本
0692login:Penguin
03/06/16 03:19ID:P+dwJ3I8亀レスですが、script(1)というのもあります。
0693login:Penguin
03/06/16 04:49ID:kWhRIl9xありがとうございます．
ユーザプロセスのTSSが保存されたカーネルスタックにforkの場合はcopy_threadで親プロセスのものをコピーし，
execveの場合は search_binary_handler（合ってますか？）でTSSが保存されたカーネルスタックを初期化するので，
これらの(struct pt_regs型を引数を持つ)システムコールをフックする場合は，
フックした関数の中でsys_*を呼び出してはいけないのですね．
で，アセンブラで書くにしてもどうやってモジュールで呼び出せばいいのでしょうか？
自前の処理の関数へのアドレスはどうやって取得すればいいのでしょうか？
それとも/usr/src/linux/arch/i386/kernel/entry.Sのcall *SYMBOL_NAME(sys_call_table)(,%eax,4)
の直前にアセンブリコードを入れるということでしょうか？
できるだけオーバーヘッドを避けたいので，これをやるなら特定のsys_*の中で処理を記述したいです．
0694login:Penguin
03/06/17 00:03ID:JrPl/8fuそゆことです。
実際のコードは.cの中にインラインアセンブラで書くか、
別に書いてリンクすればいいのではないかと。
entry.Sをいじる必要はありません。
例のサンプルならnew_setuidをアセンブラで書けば目的は達成できます。
後はカーネルと関係なく、Cとアセンブラを混ぜる話なので、
その方面のスレで聞いて下さい。
#なんでシステムコールを書き換える必要があるのか謎ですが…
#libcでoverrideすれば間に合いそうな気もしますが。
0695login:Penguin
03/06/24 17:33ID:/u6LQEV0初代Linuxから、1プロセスがディスクI/O待ちしている間、他のプロセスが停止したり
しないはずですよね。...MINIXじゃないんだから（笑）
Linuxカーネル2.5 最新開発動向
http://www.atmarkit.co.jp/flinux/special/kernel25/kernel25b.html
|■プリエンプティブルカーネルサポート
| ：
|音楽を再生するときは、通常アプリケーションからオーディオバッファへ数ミリ〜数十ミリ秒
|間隔でデータを転送し、オーディオバッファにためられたデータが順次再生されていく。だが、
|次の音をバッファに転送しなければならない状態であるにもかかわらず、ディスクアクセスな
|ど、場合によっては数十ミリ秒程度の遅延時間がかかるシステムコールを処理してしまうと、
|その処理時間にCPUが引きずられる。
正しい説明は、こっちで合ってますか？（こっちは kernel2.6 だけど）
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_04a.html
0696login:Penguin
03/06/24 21:10ID:lLx7L/ffその引用は2.4までのものでしょ?
2.4までは実行中のプロセスが完了するまで割り込めないと思うけど。
バッファにデータを転送する前にディスクアクセスするようにスケジュールされていたらそうなるんじゃない?
で、引用元には2.6ではカーネルプリエンプションが可能になるのでこういった事態を抑制できると書いてある。
プロセスA,B,C,DがA→B→C→Dの順でスケジュールされいて、Bの実行中にAが割り込みをかけたとする。
【2.4系以前】
Bの実行終了後に再スケジューリング。続いてAを実行する。
【2.5.4-pre6以降】
Bの実行を中断し、再スケジューリング。Aが実行された後でBが再開する。
最も優先順位の高いモジュールで他のモジュールのコントロールを行えば、
リアルタイムでI/Oをコントロールできるから組込みにも向いてると思ってるんだけど。
あってるかな?
0697login:Penguin
03/06/24 21:26ID:/u6LQEV0>その引用は2.4までのものでしょ?
ええ、そうです。
で、言いたかったのは、2.4以前だって、引用に書いてあるほどタコな動きは
してないでしょ、と。
2.4以前だって、disk I/Oを開始する時には、（preemptive ではないにしろ）
自主的にsleepして、CPUを他のプロセスに開放するから、ディスクI/Oの間、
他のプロセスが実行待ちになったりはしないでしょ、という意味なんですが。
0698login:Penguin
03/06/26 01:32ID:9kOqx0yKディスクI/Oという点に限れば697の言うとおりだが、
non-preemptiveだと、なかなかsleepしないシステムコールが
他のプロセスの足を引っ張ることは実際にあるように思う。
例えばsyncとか、多分ディスクI/Oというより、バッファ周りの
話なんだろうけど…
0699login:Penguin
03/06/26 12:15ID:w+qYBtvXそれは解ります。
言いたかったのは、DiskI/O の話だけなので...
DiskI/O で他のプロセスが待たないって話は、タネンバウム論争でも、MINIXとは違う点
として、強調していたポイントなのに、なんで、2.4 -> 2.5 への preemptive 化の説明に
これを持ち出すかなぁ、と。
0700login:Penguin
03/06/26 20:31ID:wJ+hhIcyまだまだ初心者なんですけど、
この本を全部読みきって70%理解したら大分詳しくなれるんでしょうか？
他にはどんなことを勉強すればいいのでしょうか？
厨房な質問ですいません。
0701login:Penguin
03/06/26 21:09ID:8PE+W9mOで、何をやりたいの？
0702743
03/06/26 23:58ID:Ryip/f5bコンパイルしようとすると、make modules のところで、
CC [M] drivers/net/defxx.o
drivers/net/defxx.c:202:2: #error Please convert me to Documentation/DMA-mapping.txt
make[2]: *** [drivers/net/defxx.o] エラー 1
make[1]: *** [drivers/net] エラー 2
make: *** [drivers] エラー 2
といったエラーを出して止まってしまいます。
ググッてみても解決につながる情報が見つからなくて・・・
そもそもこの#error Please convert me というのは
何なのでしょう？ どうすればエラーを回避できますか?
0703login:Penguin
03/06/27 07:48ID:47Hwz5yO$ dmesg | head -1
Linux version 2.5.73 (root@=======) (gcc version 3.3 (Debian)) #1 Fri Jun 27 06:46:45 JST 2003
"module-init-tools" の0.9.9以上が入っていないとカーネルをコンパイルしたあとで最後にdepmodするところでこける。
その他 Documentation/Changes の"Minimal Requirement"に記載されている、特定のバージョンのパッケージが必要。
最初 "Preemptible Kernel" を試したが、bashをexitするときなどに
ときどきカーネルがOopsとかナイスなメッセージを出すので、外した。
カーネルモジュールの名前がFreeBSD式の"なんとか.ko"になっている。
bdflushがどうので/sbin/updateがobsoleteだからinitscriptを直せ、とか警告される。
サウンドモジュールがなにやら"unsafe"とかで。
lsmod すると
> cs4281 49152 1 [unsafe]
のような間抜けなステータスが出る。rmmodできない。
i810のdrm/agpgartカーネルモジュールがまずいらしく、Xのdriを有効にできない。
> (II) I810(0): [agp] GART: no dcache memory found
> (II) I810(0): [dri] Unable to allocate backbuffer memory. Disabling DRI.
~~
> (WW) I810(0): xf86AllocateGARTMemory: allocation of 1024 pages failed
> (Cannot allocate memory)
---
とりあえずvtを切替えても落ちることはない(以前はよく落ちた)。
dri.sourceforge.netにあるカーネルdriモジュールは kernel2.5では使えないようだ。
これ以外は、今のところちゃんと動いているが、ちょっとだけ不安。
0704702
03/06/27 21:05ID:z7RNnbMR0705login:Penguin
03/06/28 00:51ID:V5nJnO59親切に
Please convert me to Documentation/DMA-mapping.txt
と言ってくれているので、まずはドキュメントを読んで見ればいいのでは？
0706login:Penguin
03/06/28 13:49ID:Vom+2tH9もちろん。そして、そのもとの文も、そうはいってないと思う。
それは、プロセスaのdiskI/Oまちの間プロセスbが止まると読むのではなく、
(おそらくだれか(a)の要求に関連する)disk I/Oの処理がプロセスbのスケジュー
リングを遅延させることを言ってるのだとおもう。プリエンプティブカーネル
(と、プライオリティつきスケジューラ)はそれを改善するものだから。
0707login:Penguin
03/06/29 13:50ID:S956rOO5>それは、プロセスaのdiskI/Oまちの間プロセスbが止まると読むのではなく、
>(おそらくだれか(a)の要求に関連する)disk I/Oの処理がプロセスbのスケジュー
>リングを遅延させることを言ってるのだとおもう。
うーむ。
何度読んでも、そうは読めないなぁ。それと、そもそも
>エンプティブカーネル (と、プライオリティつきスケジューラ)はそれを改善するものだから。
という理解も間違ってませんか？
2.4だって、I/O処理自体が、スケジューリングを遅延させているわけではないですよね？
自主的 sleep が入らないような類いのシステムコールが、再スケジューリングの遅れ
を発生させるのではありませんか？
http://www.atmarkit.co.jp/flinux/special/kernel26/kernel26_04a.html
上のURLでは、I/O処理完了にともなうハードウェア割り込み用ルーチンが起動した
場合にも、再スケジュールするようになりました、といっている感じですよね。
0708login:Penguin
03/06/29 23:08ID:/oTz8bWl漏れの理解でもそうだと思う
2.4では、自分でsleepするか、システムコールの終わりの
ユーザランドに戻る直前でしか、コンテクストスイッチは起きない。
カーネル内でいくら割り込みが起きても、割り込まれたプロセス
の実行に戻る。
プリエンプティブカーネルならば、割り込みがおきたところが
クリティカルセクションでない時には、割り込みハンドラの実行が
終わった所で再スケジューリングされる。
0709login:Penguin
03/06/29 23:53ID:mQ4EYUec割り込みから抜けるときも、ユーザーモード実行中でneed_resched立っていれば
schedule呼びます。
でないとcpu握ったままのプロセスがつくれてしまう。
0710login:Penguin
03/07/02 01:58ID:VujfXoME0711login:Penguin
03/07/02 02:11ID:kUFisWUNエイヤと、5秒待ち合わせ！みたいな良い加減さは
Linux らしくて涙チョチョ切れるね。
2 - 4 SMP くらいだと、問題にならないのだろうけど。
0712login:Penguin
03/07/06 21:37ID:VzJQlVRaint did_exec:1;
というメンバがあるんですが，これはどういう意味でしょうか？
0713直リン
03/07/06 21:42ID:wYFJkOTE0714login:Penguin
03/07/06 21:54ID:/k97neyg0715login:Penguin
03/07/06 22:50ID:wK3uN9NXbit fieldだね。
"int did_exec:1"と書くと
did_exec変数の下位1bitのみだけが有効になり、
0か1しか設定されないのさ。
0716login:Penguin
03/07/07 00:12ID:WcWZ6n6e0か-1ではないのか?
0717login:Penguin
03/07/07 00:18ID:XJtR7Wyv普通は1に解釈しない？
どーせ1bitしかないからnot 0であればいいんだが。
0718712
03/07/07 00:51ID:CYZ75cVfアホな質問してすいません．
今度からはもう少し調べてから質問します．
0719login:Penguin
03/07/07 22:00ID:kPsRFwM6うん。0,1でいきたいので struct { int a:1; } s = {1};とか初期化しちゃう
けど、結局のところ解釈はコンパイラがやるので、例えば s.a >0 ? は偽です。
てか s.a==-1? が真になる。上位1bitが符号だから、それで正しいんだと思う。
0,1にしたければ unsigned int ですね。初期化とも矛盾しちゃって気持悪いし。
0721login:Penguin
03/07/08 00:16ID:wvWko+bEっていうか、task_struct構造体の
did_exec変数は、名前の通りフラグに使うわけだから
0か0以外の値で判定するだけいいわけです。
実際にsys.cファイルには
>if (p->did_exec)
> goto out;
ってなってるし。
ちなみにsys.cファイルのコメントには以下のメッセージが。（ｗ
* Auch. Had to add the 'did_exec' flag to conform completely to POSIX.
0722login:Penguin
03/07/08 01:23ID:a4iER9hA0723login:Penguin
03/07/12 12:47ID:Q71PnbZR0724login:Penguin
03/07/13 22:08ID:UrPfG9sVおいての応答性が上がったけど、コストパフォーマンスが落ちた
ような気がする。
やはり、応答性とコストパフォーマンスはトレードオフなのかな。
以下は自作プログラムによるテスト結果
【１分間のファイル読み書き回数】
｜2.4.22-pre5｜2.4.21
―――｜――――――｜―――――
１回 ｜2588771 ｜2808551
２回 ｜2573318 ｜2865419
３回 ｜2569311 ｜2878404
４回 ｜2576775 ｜2870706
５回 ｜2578199 ｜2868286
６回 ｜2571464 ｜2865638
７回 ｜2588162 ｜2868531
８回 ｜2595950 ｜2863878
９回 ｜2606366 ｜2878016
１０回｜2604069 ｜2869487
平均 ｜2585238.5 ｜2863691.6
2.4.22-pre5の方が１分間のファイル読み書き回数が減少している。
0725login:Penguin
03/07/13 22:14ID:TbuOUgH9アレ(Xとかの応答性向上パッチ)がはいったんだっけ? もしあれなら、あれは
いままで相対的にI/OにCPUが渡りすぎてたのを、そっちを減らしてかわりにX
に割り当てる量を増やす"改善"をするパッチだから、当然I/O性能はおちます。
0726login:Penguin
03/07/13 22:28ID:UrPfG9sV>コストパフォーマンスの評価式は? それともパフォーマンスのことなのかな。
自分が言いたかったのは、多重プロセスがI/O処理中におけるCPU応答性のことです。
>アレ(Xとかの応答性向上パッチ)がはいったんだっけ? もしあれなら、あれは
>いままで相対的にI/OにCPUが渡りすぎてたのを、そっちを減らしてかわりにX
>に割り当てる量を増やす"改善"をするパッチだから、当然I/O性能はおちます。
それは、agp関連の事ですか？
ちなみ、GUI環境ではなくCUI環境でテストしました。
0727login:Penguin
03/07/13 23:14ID:ujCbFKxOChangeLogを見る限りは入ってないなぁ。
io schedulerの修正入ってるから、そっちの影響かも。
関係あると思えないBUG fixなんだけど。
0728724
03/07/13 23:29ID:UrPfG9sV>>726で言ってる、
>>コストパフォーマンスの評価式は? それともパフォーマンスのことなのかな。
>自分が言いたかったのは、多重プロセスがI/O処理中におけるCPU応答性のことです。
ではなくて、プロセスがdisk I/O処理が終了するまでの合計処理時間です。
0729login:Penguin
03/07/14 02:53ID:YDflspfA0730login:Penguin
03/07/15 03:41ID:kOKraebZヤバくない？
■ このスレッドは過去ログ倉庫に格納されています