dragonfly bsd どうよ

1 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/06/29 22:31] dragonfly bsd どうよ なんか面白そうだが。 24 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 00:58] 軽量スレッドが売り文句らしいが/.の記事だけでは良く分からん ttp://slashdot.jp/bsd/04/03/14/1417235.shtml?topic=26 25 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 01:21] N+I2004のBSD BOFのスライドでは結構細かく解説していたよ。 あの発表をみて、ちょっとインストールしてみようかなと思った人も多かったみたい。 どっかに.pptを公開してくれないかな。 26 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 09:34] 余計な時間をかなり横で喰われて肝心の発表がかなり飛ばされていたからなぁ... > N+I BOF 27 名前：名無しさん＠お腹いっぱい。 [04/07/07 10:27] で、誰か実際に使ってる? インストーラ(LiveCDで手で入れるのじゃない方の)は試してみた? 28 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 12:17] カーネルいじるわけでもない人がこれ使って何か楽しい事あるのかな 29 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 16:12] んじゃ、FreeBSD5とDragonflyBSDとでApache2のパフォーマンスの違いを測定して楽しむ。 30 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/07 16:31] SMPだと違いが出そうだな。 31 名前：名無しさん＠お腹いっぱい。 [04/07/07 17:13] FreeBSD5となにがどうちがうの？ 32 名前：名無しさん＠お腹いっぱい。 [04/07/08 02:45] >>31 カーネルのスレッド機構やメッセージングAPIとか、らしい。 しかしDillonてLinuxからBSDに移ってきたり自分でBSD作ったりと 移り気なやっちゃな 33 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/08 02:49] >>32 LinuxからBSDに移るのは移り気だが、 自分で作りたいと思うのは単に向上心かと 34 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/08 06:30] >>32 なので、差異が出てくるのはSMP環境でMT対応アプリを使う場合。 ってことで、現時点でそのあたりで一般的なアプリといえばApache2 ぐらいなので、>>29の話が出てくる。 35 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/08 10:21] SMP環境といっても、これからはマルチコア化で性能稼ぐ方向に あるらしいから、特別な環境というわけでもないんだよね。 36 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/08 12:39] SMPマザーでapache2をMPM=WORKERで動かして、FreeBSD5とDragonflyでどのぐらい違うかだよな。 37 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/10 02:14] はじめてのBSD体験になりました 蟹NICの認識どうすればよいんだ rouge入っててﾜﾛﾀ 38 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/10 02:34] 初めて過ぎてISOをブートCDにする方法すら分からん（汗 39 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/10 02:44] www.onlamp.com/pub/a/bsd/2004/07/08/dragonfly_bsd_interview.html 40 名前：名無しさん＠そうだ選挙に行こう [04/07/11 14:35] rogue入っているなら、Dragonfly支持 41 名前：名無しさん＠そうだ選挙に行こう mailto:sage [04/07/11 14:43] GUIに力を入れるってのはいいね ぬるユーザのおいら向け 42 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 20:35] benchmark マダー(AA略 43 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:20] ドラゴンフリャーBSD 44 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:21] >>43 それは邦訳版をエビフライBSDにしろという圧力ですか？ 45 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:38] オレ竜BSDかよ 46 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:44] 　　 　　　　　　　　　　　ﾍ　へ 　　EbiFly BSD　　　:| / ／ 　　　　　　　　　　　 .;: ":;. 　　　　　　∧∧,..,.. ;'､., : 、 　　 　　　;'･-･o､:、.: :　;:' 　 　　　　　　'､;: ...: ,:. :.､.: '　　 　　　　　　　｀"∪∪''ﾞ 　　　 47 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:51] 同じコードではコンパイル出来ない事態に陥ったら*BSD系じゃ無くなるね 48 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/11 23:54] 　　　　　　　　　　　　　　,.、,､,..,､､.,､,､､..,_　　　　　 　／i 　　　　　　　　　　　　　;'｀Dragonfly BSD:.:ﾞ:｀''':,'.´ -‐i 　　　　　　　　　　　　　'､;: ...: ,:. :.､.:',.: .:: _;.;;..; :..‐'ﾞ ￣ ￣ 　　　　　　　　　　　　　　｀"ﾞ' ''`ﾞ `´ﾞ｀´´´ Dragonfly BSD ￣￣∨￣￣￣￣ 　　　　.∧∧ 　　,.、,(ﾟ∀ﾟ )　　　　 　／i 　;'｀;、.　:,.:∪｀ﾞ:ﾞ:｀''':,'.´ -‐i 　'､;:.: .､.:',.: .:: _;.;. :.‐'ﾞﾞ~ ￣ 　　｀｀　U U 　　　　,.、,､,..,､､.,､,､､..,_　　　　　 　／i 　　　;'｀;、､:、. .:、:,　:,.: ::｀ﾞ:.:ﾞ:｀''':,'.´ -‐i 　　　'､;: ...: ,:. :.､.∩.. .:: _;.;;.∩‐'ﾞ ￣ ￣ 　　　　｀"ﾞ' ''`ﾞ //ﾞ｀´´　　 | | 　　　　　　　　//Λ＿Λ　 | | 　　　　　　　　| |（　´Д｀）// ＜Dragonfly BSD 　　　　　　　　＼　　　 　 | 　　　　　　　　　＼　　 　 | (ry 49 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 00:04] 俺もNuggetBSD作ろうと思います。 50 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 06:35] >>41 LiveCDの方にはX入って無かったよ 51 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 08:37] >48,46 龍ふりゃー だったら fly じゃなくて fry なんじゃネーノ? あとどうせならデーモン君が fork で食べているとかそんな絵にしないと。 52 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 13:38] お前らは中学を卒業できていないDQNの群れですか。 53 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 15:42] いいじゃんそんなBSDがあっても 人生を楽しく生きるコツは童心を忘れない事だ 54 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 19:58] FlyBSDとしてFreeBSD2系のメンテを行いたいと思います。 55 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 21:04] EbiFry BSDとしてスキンを用意して邦訳すると。 56 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 22:57] スキンは岡本理研でいいですか? 57 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 23:46] それじゃエビフライじゃなくてイカフライだろ 58 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/12 23:55] このスレだけノリがUNIXっぽくないな 59 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 00:06] UNIX板は下ネタが多いので無問題。 60 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 22:00] 来ましたよー 61 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 22:16] いらっしゃいませ。 62 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 22:17] (･∀･)ｴｯｺｰ 63 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 22:21] >>50 ＧＵＩに力入れるってのはもしかしたらＸサーバー使わないのかもね MaxOS Xということか 64 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/13 23:23] Frescoが標準だったりして 65 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 01:06] bsdnews.com/view_story.php3?story_id=4639 1.0でたよー。 日本のミラーだとallbsdが近いかな 66 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 10:29] >>65 インストーラではなくプリインストールブートディスクだね Knoppixみたいなもんだ とりあえず芋かったデーモン君がリストラされてたことにﾜﾛﾀ 67 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 12:37] デーモン君のフェードアウトはGUIへの本気度の表れと見た 68 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 13:17] デーモンダサイ、死ね 69 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 18:37] インストーラのバグで、パーティションが既に存在するディスクに fdiskを使った場合、後ろのほうにあるパーティションの情報を 吹き飛ばしてしまう可能性があるらしい。パーティションの切り直しが 必要な人は修正版が出るのを待ったほうが無難。 70 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/14 18:54] CUI・GUIの起動画面に使えるエビフライを依頼するしか俺たちに残された道は無い。 71 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 00:27] GUIに力入れるならまずインストーラからGUIにしてほしいね。 そーいやQt使ったインストーラて見ないな 72 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 00:33] FreeBSD 4.x と DragonFly でベンチ取ろうと思うんだけど、何か有用な ベンチ知ってる人いますかー ? >>36 のを 4.x で取ろうと思ったら apache2 を worker でビルドできんかった。 73 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 00:44] そりゃそーだ。 currentは最近マズーだから5.2.1Rで取ってみたら？ acpiはオフで。 74 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 01:39] 5.x にはあげられない理由がちとありまして。。。 4.x で何とかならないかな、と。 75 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 02:33] なんとかすれば。というか普通にデフォルトでビルドすればいいじゃん。 76 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 02:57] そろそろBSDもカーネルにGUI関係を組み込んでもいいころだね 77 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 04:29] ・WindowsのようにカーネルへGUI関連の機能を埋め込む。 ・BeOSのようにドライバ用の仮想空間(インターフェイス)を作る。 ・TRONのようにユーザーランドを１プロセスにする。 ・MacOSのようにX11以外のウィンドウシステムを作る。 78 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 10:59] >>76-77 むしろMattは、いままでカーネル中心だった機能をユーザランドへ ひっぱり出そうとかいってたはずだけど。 79 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 13:52] DragonflyのGUI重視ってのは、 Linuxのディストリみたいに、インストールすると、 KDEなり、GNOMEなり標準搭載されたGUIで起動できるって事なのかな? 80 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 15:36] んなアフォな 81 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 16:59] >>79 「GUI重視」というのはソースは? 82 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 19:02] >>78 古いWindowsNTみたいになるのか？ 83 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 19:05] GUI重視ではなくて、GUIにも力を入れるよと言ってるだけだね。 ttp://slashdot.jp/bsd/04/03/14/1417235.shtml?topic=26 84 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 19:48] userlandが4ベースというのが激しく気にいらんなぁ。 85 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 20:13] でもrcNGが入ってるのはうれしい。 86 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/15 20:15] >>83 なるほど。 | ターゲットは『サーバ』、それとも『デスクトップ』? という質問に対して |両方だよ、どっちか一つというふうに答えが出る質問じゃないよね。 |「サーバ向け」ってのはつまり安定性と堅牢性ということで、 |「デスクトップ向け」はそのままの状態でGUIが使えるってことだよ。 という話をしているので、「力を入れる」というわけでもないんじゃないの? >>84 どのあたりが? 87 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/19 08:59] (´･ω･`)ｴｯｺｰ... 88 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/19 20:07] インストールしてみたけど、時計がはえーです。普通の 2倍くらいのはやさで 時を刻んでます。 acpi も切ったりしてみたけど、変わらず。同じような症状出た人いませんか ? 89 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/20 06:14] >>88 ワラタ 90 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/20 07:21] >>88 その場合、パフォーマンスも2倍になるのか? だったら素晴らしい機能だ。 ……という冗談は置いといて、似たような話をFreeBSDでも聞いたことが あったような気がする。 確かsysctlでkern.timecounter.*をいじるようなことを言ってたような…… 91 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/20 10:18] >>90 残念ながらdflyにkern.timecounterは存在しない。 MLのバグレポートではP166が実際に速くなるらしいね。 |Re-syncing the clock is not the problem. :) Having a CPU that is |running at hyperspeed and causing heat problems is. When the system |clock starts running faster, the whole system starts running faster. |I've watched the P166 run through a buildworld in very little time |(around 30 minutes wall time). The resulting binaries don't work, 92 名前：88 mailto:sage [04/07/20 22:27] >>90 パフォーマンス的な話をすると、同じ処理をするのに(時間が 2倍はやいので) 2倍の時間がかかります。つまり、 1/2 です。 :) >>91 hw.i8254.timestamp が追加されて現在調査中、みたいな感じですね。 ML を注視しつつ解決を待ちます。 93 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/21 01:50] > The resulting binaries don't work, って、おいおい… 94 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/21 23:03] なんでこんな状態で1.0にしちゃったんだ。リリースマネージメントがアレすぎ。 95 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/21 23:11] そらマネジメントする奴がおらんからな。 >>94 やってみるか？ 96 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/21 23:30] version1.0じゃなくてupload1.0って意味にしとこう。 97 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/22 10:28] >>94-95 dot-zero releaseってのはそういうもん。ましてや1.0だしね。 お前らがナイーブ過ぎるんだよ。 98 名前：名無しさん＠お腹いっぱい。 mailto:age [04/07/26 01:21] MacOSX並のGUIまだー　ﾁﾝﾁﾝ 99 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/07/26 02:43] >>98 gnustep(違 100 名前：名無しさん＠お腹いっぱい。 [04/07/31 17:35] 100age 101 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/01 20:27] 今日cvsupしたんだけれど、 CCVERがgcc34でbuildworld通った人います？ 102 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/01 21:22] LiveCD版しか使ってない ↓どう？ 103 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/01 21:41] >>101 無理です。あきらめて一度gcc2でbuildworldしましょう。 104 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/01 23:56] >>103 了解っす。 gcc34でbuildworld出来ないのって、 たまたま今は出来ないって事なのかな〜 105 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/02 00:35] まあ、userlandのベースがFreeBSD4.xだから、gcc3でコンパイルできなくても文句は 言えないってことなんだろうけど… 106 名前：103 mailto:sage [04/08/02 08:05] >>105 違う違う、そういう意味じゃない。gcc3用のクリーンアップはずっと 昔に済んでるよ。問題なのはbuildworldの最初の方にやるいくつかの サブターゲットはシステムにインストールされているコンパイラを使うん だけど、CCVER=gcc34になっているとそのコンパイラが(存在しない) gcc34を使おうとして失敗するというものだったはず。もしbsd.cpu.mkに 怒られるんだったらソースツリーの中じゃなくシステムの方の/usr/share/mkを 使っているということだから、CCVER_BSD_CPU_MK=gcc2と設定すればいいんだけど まあ試してみて。 107 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/02 23:37] >>103 CCVER_BSD_CPU_MK=gcc2 設定したらbuildworld通りますた(`･ω･´) ついでにmake.confも見直したんだけれど、 /etc/defaultsにもmake.conf入っていてびびった。 FreeBSDも最近は/etc/defaultsに入ってるのかな。 108 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/03 03:59] 4.xでは/etc/defaultsに入ってる 5.xでは違うところに入ってる 109 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/08 06:41] hrs氏の日記にDragonFlyの話題が。 ttp://www.allbsd.org/~hrs/diary/200408.html#d0801 日本語の文書の中では、今のとこ一番わかりやすいと思う。 110 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 20:08] ポート/メッセージモデル DragonFlyはLWKTに同調する軽量なポート/メッセージAPIを備える予定です。 ポート/メッセージAPIの概念は非常に単純です。まずメッセージを組み立て、 目標となるポートへ送り、あとで自分の応答ポートに返事が来るのを待つ というものです。この単純な概念にもとづいて、高度な機能を構築し、 洗練化を行います。このメッセージングシステムの機能を理解するには、 まずメッセージがどのように送信されるのかを理解する必要があります。 基本的には以下のように動作します: 111 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 20:49] メッセージAPIはこの基本的は構造を同期/非同期メッセージ関数に内包します。 lwkt_domsg()はメッセージを同期的に送り、返答を待ちます。この関数は 目標ポートにヒントを与えるためのフラグをセットします。それはメッセージが 同期的にブロックされることを示すもので、目標ポートがEASYNCを返した場合 lwkt_domsg()はブロックします。lwkt_sendmsg()はメッセージを非同期的に 送りますが、目標ポートが同期的なエラーコード(つまりEASYNC以外全て)を返した 場合、lwkt_sendmsg()はもう完了したメッセージを返答ポート自身のキューに手動で 入れます。 112 名前：名無しさん＠中学生英語 mailto:sage [04/08/11 21:08] >>110-111 素晴らしい !! wids.net/balk/dragonflybsd.messaging.j2.txt 113 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 21:10] 推測できると思いますが、目標ポートのmp_SendMsg()関数はメッセージを どう扱うかを完全に制御します。メッセージフラグによって渡されたヒントが どのようなものであっても、目標ポートはメッセージに対して(呼び元から 見て)同期的にふるまって応答することも、メッセージをキューに入れてEASYNCを 返すこともできます。一般的にメッセージ処理は発信者から見て「ブロック」 すべきではありません。つまり、メッセージを同期的に処理することがブロック につながるのであれば目標ポートは同期的に処理してはいけないということです。 そのかわりに、自身のスレッドのキュー(目標ポートの構造体に、便利なように 埋め込んであるメッセージキュー)に入れて、EASYNCを返すようにします。 114 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 21:48] : (このパラグラフは特に変更しなくていいよね) ここで覚えておくべき重要なことは、もっともよい最適化とはmp_SendMsg()に よる直接の実行で、単純なサブルーチン呼出しの他には実質的にオーバヘッドを 伴わないことです(訳注: no more〜thenはDillonのいつもの釣りね)。 キュー処理もせず、応答ポートをいじることもなく、ということです。もし メッセージを同期的に扱ってよいのであれば、これは非常にコストの低い 処理ということになります。この特徴があるからこそ、性能の問題を気にせずに メッセージングインタフェースを意図して使うことができるのです。私達は たとえばMachで用いているような種類の洗練手法を使うことはあえてしません。 少なくとも低レベルなメッセージインタフェイスでは、メモリマップやポインタの 追跡といったことをしません。ユーザ⇔カーネル間のメッセージインタフェイスは 単純にmp_SendMsg()の関数ベクタを用い、それによって適切な変換をします。 そうすることで、送信側と受信側に関しては、メッセージがそれらの VMコンテキストに対しローカルになります(局所性を持つということ)。 115 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:28] 軽量カーネルスレッドモデル DragonFlyはその中核部分に軽量カーネルスレッド(LWKT)を用います。 システムのプロセスは全てスレッドと結びついていて、カーネルのみの プロセスのほとんどは事実上純粋なスレッドです。たとえば、pageout デーモンは純粋なスレッドでプロセスコンテクストを持ちません。 LWKTモデルはアーキテクチャによらないいくつかの鍵となる特徴があります。 これらの特徴はCPU間の競合を除く、あるいは減らすために設計されています。 1.システムの各CPUは自己完結のLWKTスケジューラを持ちます。スレッドは意図的に CPUに結びついていて、いくつかの特殊な状況下でのみ他のCPUへ移動することが できます。特定のCPU上のLWKTスケジューリング処理はそのCPU上でのみ直接 実行されます。これは、LWKTスケジューラ本体がスケジュール追加、除去、 CPU内でのスレッド間スイッチを、ロックを一切せずに処理できるということです。 単純なクリティカルセクションの除いてはMPロックもなにもなしにです。 2. スレッドはカーネルで動作中は他のCPUにプリエンプティブに移動されることは ありません。スレッドはブロックされている間はCPU間を移動しません。 ユーザランドスケジューラはユーザモードで実行しているスレッドを移動できます。 スレッドは非割り込みスレッドへプリエンプティブにスイッチすることは ありません(この間FreeBSD初心者スレで出た話題のやつね)。割り込みスレッドが カレントスレッドをプリエンプトする場合、割り込みスレッドが終了または ブロックした時点でプリエンプトされた方のスレッドはスケジュール状態によらず 復元されます。たとえば、あるスレッドはlwkt_deschedule_self()を呼んだあと、 実際に(別のスレッドへ)スイッチする前にプリエンプトされる可能性があります。 これは問題ありません。なぜなら割り込みスレッドが完了またはブロックしたあと そのスレッドに直接制御が戻るからです。 116 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:51] 3. 上の(2)により、スレッドはCPUごとのglobaldata構造体を通じて得た 情報をロックなしにキャッシュすることができます。また、その情報が 割り込みスレッドによって変更されないと分かっている場合は、 クリティカルセクションに入る必要がありません。これによって、 いろいろな種類のデータのCPUごとのキャッシュ(訳注: 「の」の連続だ) を、事実上オーバヘッドなしに持つことができます。 4. あるCPUが他のCPUに属するスレッドをスケジュールしようとする場合は、 ターゲットCPUにIPIベースのメッセージを発行して、処理を実行します。 このメッセージはデフォルトで非同期で、このためIPIはレイテンシを 伴うことがありますが必ずしもCPUサイクルを浪費するとは限りません。 このIPIの処理はクリティカルセクションに入ったスレッドによってブロック されます。実際、LWKTスケジューラはそうします。クリティカルセクションの 出入りは安価な処理と考えられるので、ロックやバスロック命令を必要と しません。 5. IPIメッセージサブシステムはFIFOあふれによるデッドロックに対し、 送信キューの停滞が解消するのを待つ間、受信キューをスピンして処理する ことで対処します。IPIメッセージサブシステムはこのような状況下で 特にスレッドのスイッチを行いません。これによって、まれにスピンが 発生する場合があってもソフトウェアはこれをノンブロッキングAPIのように 扱うことができます。 117 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 22:59] これらの鍵となる特徴に加え、LWKTモデルでは高速割込みプリエンプション とスレッド割込みプリエンプションを両立します。高速割り込みはカレント スレッドがクリティカルセクションに入っていない場合はプリエンプトできます。 スレッド割込みもカレントスレッドをプリエンプトできます。LWKTシステムは、 スレッド割込みにスイッチしたあとそれがブロックまたは完了した場合に もとのスレッドに戻ります。IPI関数は高速割り込みと非常に似たやり方で 動作し、同じくtrapframe機能を持ちます。これはDragonFlyのSYSTIMERS APIで hardclock()やstatclock()の割込みを全てのCPUに分配するために多く用いられて います。 118 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/11 23:15] IPIメッセージサブシステム LWKTモデルはCPU間通信のための非同期メッセージシステムを実装します。 基本的には、関数ポインタとデータ引数を引数として関数を呼び出すと ターゲットCPUにそれを渡り、ターゲットCPUはそれを非同期に実行します。 これは非同期モデルなので呼び側は同期完了を待ちません。このため性能が 非常に向上し、ターゲットCPUへのオーバヘッドもおおまかには割り込み と同等程度です。 IPIメッセージは高速割り込みのように動作します...つまり(クリティカル セクションに左右されますが)ターゲットCPUで動いているものは何でも プリエンプトし、実行し、そのあともともと動いていたものに復帰します。 このためIPI関数はいかなる理由であってもブロックすることは許されません。 IPIメッセージはスレッドをスケジュールしたり他のCPUに属しているメモリを 解放するといった処理をするのに用いられます。 IPIメッセージ処理は少なくとも6個の主なLWKTサブシステムで多用されています。 それらには、CPUごとのスレッドスケジューラ、slab allocator、メッセージ サブシステムが含まれています。IPIメッセージ処理はDragonFlyに本来的に 適応したサブシステムなので、Big Giant Lockを必要とせず、使用してもいません。 全てのIPIベースの関数は従ってMPセーフである必要があります(そうなっています)。 119 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 09:25] これって、ひとつの資源に対して単一のCPU&スレッドを張り付けることで、排他制御をシンプルにする というおおざっぱな理解であってる? スレッド切替が頻繁に発生してパフォーマンスで劣るんじゃないかとか、 スレッドの優先度制御をどうするかとか、いろいろ問題もありそうだけど、 おらワクワクしてきたぞ。 120 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 12:25] IPIベースのCPU同期サブシステム LWKTモデルは、汎用でマシンに依存しないCPU同期APIが備わっています。 このAPIによって、デリケートなデータ構造にアクセスしている状態の ターゲットCPUを既知の状態に移行させることができます。このインタフェイスは 主にMMUのページテーブルを更新するのに使用されています。たとえば、 もし適切なロックを確保していたとしても、ページテーブルエントリの モディファイビットをテスト、クリアしたあとにページテーブルエントリを 削除するのは安全ではありません。これは、他のCPUで動作しているユーザランド プロセスがそのページを読み書きする可能性があるからで、その場合向こう側のCPUが TLBを書き戻すのとページテーブルエントリをクリアしようとする処理の間に レース状態が生じます。適切な解決は、ページテーブルエントリへ書き戻す 可能性のあるCPU(つまりpmapのpm_activeマスクでセットされている全CPU)を まず既知の状態に移行し、変更処理をしてから、各CPUのTLBを無効化するリクエストに よってCPUを解放するという方法です。 DragonFlyに備わっているAPIにはデッドロックがありません。複数のCPU同期処理が 並行に動作することが可能で、これはCPU同期イベントの主導権を握っているスレッド にもあてはまります。これは柔軟なしくみですが、CPU同期インタフェイスは制御 された環境で動作するため、コールバック関数はIPIメッセージサブシステムで 用いられるものとちょうど同じように動作する傾向にあります。 121 名前：名無しさん＠お腹いっぱい。 mailto:sage えっちねた板の連貼りみたいだ [04/08/12 14:21] 同期トークン 同期トークンはいくつものスレッドが同時につかめます。トークンをつかんでいる スレッドは、同一のトークンをつかんでいる他のスレッドが同時には実行しない ことが保証されます。 一つのスレッドは同期トークンをいくつでもつかむことができます。 あるスレッドは、イールドまたはブロック条件を通じて同期トークンを つかむことがありますが、そのスレッドが(ブロックあるいはイールドされて) 実行中でない間、それらのトークンをつかんでいる他のスレッドが実行する 可能性があることを考慮に入れる必要があります。 理論上、同期トークンの機構から起きるデッドロック状態で解決できないものは ありません。しかし、初期の実装ではトークンを同時につかんだ場合にライブロック の問題が起きる可能性があります。 同期トークンは、同一のトークンをつかもうとする割り込みが他のスレッドを プリエンプトしてしまうことから保護するのにも使われます。これはBig Giant Lock (BGL; MPロックともいう)とは若干違った作用があります。BGLは同一CPUの割り込みを インターロックすることはありません。重要なことは、プリエンプションによって 一時的に他のスレッドへのスイッチが起きることがあるとしても、トークンの原子性 (?atomicity)プリエンプティブ条件によって維持されるということです。トークンの 原子性(?atomicity)を維持するためにspl()レベルやクリティカルセクションに入る 必要はありません。 同期トークンはプリエンプティブは割り込みが起きるのをさまたげることはありません が、割込みをブロックして再スケジュールさせることがあります。スレッド化されて いない高速割り込みやIPIメッセージング割り込みはトークンをつかうことが できません。それは処理に必要なスレッドコンテキストを持っていないからです。 そのかわり、これらのサブシステムはクリティカルセクションを使うことで 排他制御をします。 122 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 19:40] DragonFly - ユーザAPI 移植性のあるユーザAPIを作る 多くの標準的なUNIXシステムでは、生の構造体データを含む多種のデータを、 システムコールテーブルを通じてやりとりします。ユーザプログラムがそれ 自身より古いあるいは新しいカーネルとやりとりする上で最大の障害は、 これらの生の構造体データはよく構造が変わるということです。最も厄介なのは ネットワークインタフェイス、ルーティングテーブルのioctl、ipfw、 ps,vmstatが直接アクセスするプロセス構造体などです。しかし、stat()や readdir()のようなどうということのないシステムコールでさえ問題があります。 もっと一般的な言い方をすれば、システムコールはそれ自体が移植性の問題を 生むことがあるということです。 このプロジェクトの目標として以下のものがあります。 (1) 実質全てのシステムコールをメッセージベースにする、 (2) 構造体の情報を、直接ではなく機能や要素のリストを通じて渡すようにする、 (3) 汎用の「中間層」を実装する。 (3)はある種のエミュレーション層のように見えるもので、管理はカーネルが行うが ユーザ空間にロードされます。この層は全ての標準的なシステムコールAPIを実装し、 それらを適切なメッセージに変換します。 例えば、Linuxエミュレーションはカーネルランドでなく(カーネルに保護された) ユーザランドで動作します。FreeBSDのエミュレーションも同じように動作します。 実際「ネイティブ」なプログラムもシステムコールという私達がよくなじんだものを 見るためにエミュレーション層を通ります。ただ違うのは、ネイティブな プログラムはエミュレーション層が存在し、ユーザランドから直接アクセスできる のを知っているので、ただカーネルに入ってすぐにエミュレーション層に戻る ためだけに余分なINT0x80(でも何でも)を無駄にしない、ということです。 123 名前：名無しさん＠お腹いっぱい。 mailto:sage 誰かチェックしてね [04/08/12 19:42] [User API続き] システムコールをメッセージベースの構成要素に変更することによるもう一つの 大きな利点は、ユーザランドスレッドの問題を完全に解決できるということです。 もう複数のユーザランドスレッドを処理するのに複数のカーネルコンテクストや スタックは必要なくなり、プロセスあたり一つのカーネルコンテキストとスタック があればよいのです。ユーザランドスレッドはシステムの各CPUごとに実プロセスを 生成するのにrfork()を使い続けますが、他全ての処理はスレッドに対応した エミュレーション層を使えます。実際、ほとんど全てのユーザランドのupcall (コールバック)はカーネルから直接発行されるのではなくユーザランドの エミュレーション層から発行します。以下はスレッド対応エミュレーション層 が動作する例です: [コード] たったこれだけです。DragonFlyが実装する「本当の」システムコールは 送信、受信、待機に必要な原始的なメッセージ通信機能のみです。 他はエミュレーション層を通過します。もちろん、カーネルの側では メッセージコマンドはFreeBSD 4.xにあるのと同じ規模のディスパッチ テーブルにたどりつきます。でもサブシステムがメッセージベースになっていく につれて、syscallメッセージはよりいっそうこれらのサブシステムに 統合されてゆくので、「メッセージ」を処理するためのオーバヘッドは 最終的には独立したシステムコールを処理するオーバヘッドよりも小さくなる でしょう。「エミュレーション層」はユーザランドプログラムが期待するものと カーネルが期待するものを分離するブラックボックスの役割をするので、 移植性を確保することははるかに簡単になります。エミュレーション層は カーネルといっしょに更新する(または後方互換性のあるバージョンを作る) ことができるため、ユーザランドのバイナリからは移植性の問題は見えなく なります。 加えて、メッセージパシングモデルが提供する利点を全て受けられます。 それはデバッグや他の目的のためにシステムコールに割込んだり、 たとえばセキュリティ環境のもとづいて特定クラスのシステムコールを 無効にしたり変更したりするといったセキュリティ層をカーネル内に 構築するというものです。 124 名前：名無しさん＠お腹いっぱい。 mailto:sage [04/08/12 23:15] wids.net/balk/dragonfly-jt-status.html

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef