[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: log of meeting and bof
In message <20030710.140333.143307736.kawamoto@wide.ad.jp>
on Thu, 10 Jul 2003 14:03:33 +0900 (JST),
KAWAMOTO Yosihisa <kawamoto@tenjin.org> wrote:
> 総会とbofのログって神戸さんに取って
> もらってたんでしたっけ?
完全に忘れていました。
--
Takahiro Kambe <taca@back-street.net>
総会
60 / 72
1/10の8人以上なので、成立
pig
CVS + Web
momo
???
lala
go from IIJ
commet
BOF
o SSD/Linuxその後 Tamotsu Kanoh
kanoh@ssdlinux.org
お笑い系ディストリビューション
- make buildできるディストリビューション
- rcorder(8)の移植
めげた。
- pkgsrc対応(zoularis)
まだ
- マスコットキャラのデザイン
ペン入力のタブレットをかったが、
不器用なので
- ドキュメント
http://openlab.plathome.co.jp/ssdlinux/
やってしまったこと
PowerPC on i386 cross build(ユーザランド)
# cd /usr/src
# bmake CROSSS_BUILD=powerpc OPENBLOCKS=obs266
DESTDIR=/home/dest RELEASEDIR=/home/release release
元々はglibcのメジャーバージョン・アップ
configureの枠組みの音頭取りがいない
OpenBlockS標準OS
おかげで、転職後も安心
近況
OpenBlockS 200S/R, 266に対応
kernel 2.4.20
USAGI stable release 4.1
glibc 2.3.1
gcc 3.2.3
今やってること
glibc 2.3.2
OpenBlockS 50対応
kenrel 2.4.21
gcc 3.3
Q&A
なし
Q: OpenBlockSの購入者からの反応はあるか?
A: RedHadと違うので混乱する。しってる人は自分で入れ替えちゃっ
てる。
ファームを組み込む機能が含まれているので、方面によっては嬉
しいらしい。
o NetBSD 0.8復刻 Tamotsu Kanoh
今さらNetBSD 0.8
目的
動作する環境の保存
そろそろ意図的に残さないと動くマシンが無くなる?
10年前に自分は何をしていたんだろう?
ハード構成
i486DX4-100MHz
16MB
IBM DORS-32160(2GB)
AIR 486EI Ver.2.21
Tsenglab ET4000AX
NIC SMG Elite16
AHA 1542B
16C550 Serial
ちゃんと動くメモリを探すのがたいへんだった。
LANはうるさい
リソース
InfoMagic UNIX CD-ROM July 1993
4.4BSD-Lite 1994(後述、これがないとだめ)
UserLandの再構築
Cryptがない。
/etc/master.passwdが平文
/usr/src/lib/libc/gen/ にcrypt.cを放り込む。
cd /usr/src/lib/libc/ && make && make install
make installの後、passwdを入れ直す。
makeする前に
objのディレクトリを作って上げる。
Repository
cvs -r netbsd-0-8 srcしてみる。
sys.386.bsd/i386がsys/arch/i386に移行
config(8)が通らない。
usr.sbin/config./main.cのCDIRが ../..
あきらめ
Boot message
短い
386BSD 0.1と区別がつかない。
XFree86 1.3
ヘッダをコピーしてあげるとコンパイルできる。
やるぜ!
NCS Mosaic-2.X-l10n
XFree86-2.0
SWiM 1.2.3 for BSD/386 2.0
NCSA httpd 1.4.2
Distribution CD iso image
o NetBSD 2.0にむけて Makoto Minoura & Noriyuki Soda
NetBSD 1.7 or 2.0
ほんとのところはどうなの?
次に、いつ頃。
声の大きな人(Jason)が2.0!と言った。
configureが潰れる。
NetBSD 7と思ってたけど相手にされなかった。
2003, X, 19103?
SMPとthreadで2.0と言っていた人はいたが、コンセンサスはない?
libcのmajor versionが上げない。
minor versionは上がっていく。
minor versionは特に意味を持ってはいないのでOK
バイナリ互換性の確保
12になるまでは上がっていた。
問題ないと思っていた。
問題があることがわかった。
上げる必要はあるか?
昔のバイナリの名前を残し、新しいものをrenameで
付けていて、何とかなってる。
古いインターフェイスが残っていく。
stdioの構造体にメンバ増やしたい問題
バイナリ互換性を崩さずに何とかする方法が考案
SMPはどうなった?
入る前のi386/MPは安定していた。
pthread使わなければ、安定していた。
SA(Scheduler Activation)
1 processに複数の実行の流れ => thread
kernel:userland
M:N か 1:1 か。
商用UNIXの殆んどはM:N
Linuxは1:1
Solarisが1:1に変わった。
+---+--+--+--+---+------+
| | | | | |
| N N |N |N | N | N | userland
| | | | | |
+------+--+--+---+------+
| | | |
| M | M | M | kernel
| | | |
+------+---------+------+
1:1
process == threadだが、
メモリの共有などはさせる。
M:N
process thread
M ≦ N
M: lwp(Light Weight Thread)
N: pthread的なthread
1:N
threadがIO待ちすると、全プロセスが止ってしまう。
non-blocking I/Oすれば良いが、バグ出るかもしれない。
SMPでも効率が悪い。
NetBSDがM:Nとした理由
1:1ではユーザランドでthreadを作ると必ずkernel thread
カーネルスレッド作らないといけない。
ユーザスレッドがいっぱいなものだと辛い。
1:1の利点
IO待ちでスレッドが切り替わる場合が多い場合は好都合
IO主体のアプリケーションではいいかも。
Solarisが変えた理由
カーネルの負荷は変わらない。
M << Nの場合に速い。
Linuxが1:1とした理由
実装が簡単(そう)だったから。
M:Nの課題
ユーザランドとカーネルスレッドの対応付けの解決
SAがその答え。
SA
+---+--+--+--+---+------+
| | | | | |
| N N |N |N | N | N | userland
| | | | | |
+------+--+--+---+------+
| | | |
| M | M | M | kernel
| | | |
+------+---------+------+
システムコールでそのまま戻る場合: そのまま
システムコールでtsleepする場合
1. kernelがlwpを作成
2. kernelからユーザランドのスケジューラがupcallを受ける。
3. kernel/lwpにユーザランドのスレッドを作成して割り当てる。
4. tsleepが終わった場合もスケジューラがupcallを受ける。
5. userlandのスケジューラが完全に状況を把握できる。
SAの利点
1. M:Nが簡単にできる。
2. kernelの変更が少ない; tsleepをプロセスからlwp
3. ユーザランドも変えなくて良い。
libcの実装も殆んどいじらなくていい。
4. SMPでadaptive lockを自然に実装できる。
mutex待ちする場合
sleep
眠って待つ
spin
ループ待ち
だいたい、mutexが必要なのは短い間
でも、context switchがないので速い。
但し、相手が眠っていた場合はsleepしないといけない。
結局
mutexを待つ相手が、
sleep → sleep
run → spin
ユーザランドのマネージャが状態をすべて知ってるのでうまいことできる。
現状はSA + SMPは嬉しくない。
adaptive lockも(ライブラリの隠れたところでできるので)簡単にで
きるが故にプライオリティが低い。
問題点
スタックが少ない。
本当に問題な点とpthreadのアプリケーションのバグが切り分けられ
ていない。
librunqueなんかでpanicするのは悪い。
実際にpthreadのできに問題があることはある。
わかりやすい論文があるから読むとわかるはずなのに読んでない。
1:1は簡単?
signalの配送をちゃんと処理しようとすると難しい。
Linuxのアプリケーションは壊れたままでも動くように作られている。
Linuxエミュレーションに実装は? ないだろう。
KSEと、どう違う?
論文にSAとの違いは述べてある、利点はあまり書いてない。
- tsleepしないスレッドが多いと1:N
context switchでupcallは今はかからない; 手を抜いてある?
- 最初にlwpをアプリケーションの数をアプリケーションが(知ってるはずなの
で)指定した方が効率が良いのではないか。
ユーザランドとカーネルランドの間の行き来が多くなってしまい、却ってタ
イマーだけの方が軽い。
- 1:1はN:Nと書くとわかりやすいのでは。
- Nasonの論文を読むとわかりやすい、元祖の論文(Anderson)も読んだ方が良い。
- KSEはFreeBSD 5.0ではシグナルの配送がいい加減だった。どのスレッドに届
くかわからない。
SMPの場合にユーザランドのスケジューラの性能が効いてくる?
- M:Nでフェアなスケジューリングは難しいのではないか、特にSMPの場合?
ユーザランドに閉じてpriorityを与えるか、kernel lwpまで含むか指定できる。
ユーザランドで走りまくる場合の方が、M:Nの方が有利
- SAとSolarisの古いスレッドは違うのか?
Solarisではlwpの数が十分に増えない。
upcallがない、ある?
この形でのupcallがないため、lwpが十分に増えない。
upcallの実装が違う?
実装 v.s. アーキテクチャ?
Solaris 2.6で対応したとアナウンス
- 1.7 or 2.0は何時でるのか?
SAがちゃんと動く。
libpthread(3)
gcc 3.3
Mo device poiling on NetBSD(work in progress) Takahiro Igakashi
Preface
knives on IRC
NetBSD 1.4Oから(NetBSD 1.4 release)
BUGなどにはよく顔を出してます。
N+IにはrealとIRCでだけ参加してます。
network周りとスケジューリング周りに興味
知識は図書館やノートにあれば良い。
回答できなくてもごめんなさい。
device polingとは
カーネルが割り込みではなくて、deviceのpollingでデバイスの状態
を検知
NICのパケット受け取り毎の割り込みは辛い
利点と欠点
割り込みを減らしてcontext switchを減らす。
polling任せなので、デバイスからのイベントを迅速に処理できない
場合がある。
http://info.iet.unipi.it/~luigi/polling/
patchの変遷
0.0 => 0.1
10周年記念の焼き肉パーティ向け
無職の間の3日間
FreeBSDでnetworkまわりのソフトウェア処理の枠組みがNetBSDではな
くて、lockの種類の差に悩まされる。
0.1 => 0.2
未実装部分を実装
0.2 => 0.3
pollingの制御をシステムワイドからNIC毎にできるようにし
た。
0.3 => 0.4
0からの再書き直し
様々な実験を行った。
バグが1つ残っているため、まだ出せないでいる。
0.4から今後
bugの修正
実装方法などの比較
fxpを対象にNICのドライバを修正。
考えてきたこと、考えてること、考えたいこと
0.3までは実行速度よりも移植を優先していた。
100BASE-TXで6M bytes/sec から7M bytes/sec しか出なかった。
(FTPによる計測)
8M から11M で推移
安定させるためには、よりよいpolling周期が必要
周期server
RTOSにみられる周期サーバ(spordadic server/slack server)ができ
るか。
- HZが1000、1ms毎くらいにpollingするとdeviceがイベント
の処理を待ってる状態になる。
何らかの方法で精度を上げた状態でないと、これら
の実装を持ってくることは無理なのか。
- RTOSとの考えの差に苦労しながら論文読んでる。
HZの考慮
1000ではなく4000などのorderがあった方がよい。
- HZを高めることへの反発
- HZを高めることで遅くなってしまわないか。
FreeBSDの実装もどうようだが、1HZあたりに数度にわたるpolling
- より汎用に扱う解があるのか?
実装方法の考慮
hardware clockのみへの依存
システムの時間を取ることによるburstやidleなどを防止す
るため
softintrとthread
hard clockからの毎Hzごとの呼び出しの受け手の実装
スレッドの方が、むらを減らすことができるのでは
ないか。
thir@thir.org
Q: i386のポートマスタから質問: 実際に負荷が軽くなるといったことの測定
は行ったか。
A: top(1)で割り込み時間を測ってみた。直接の比較はしていない。
spray(8)で測定したときの結果で調査。
Q: デバイスが忙しくなったらpollingで、そうでなければinterruptといった
制御はしているのか。
A: 監視するデーモンを用意すれば良いと思っていた。一方で2つの閾値を持っ
てやってみてはという提案があるが、TO DOとなっている。
Q: ギガビットのNICでOSの性能が落ちるという話は出ていて、NICの側でも対
応を行ったデザインのものがあるが、それに何らかの影響を与えるか。
A: ギガビットはやれていない。
device pollingの方がTCPが速くなったという報告はある。
Q: pollingの周期を動的にできるか。
A: 現状はHZのタイミングで呼ばれるだけ。
RTOSの方からのアイデアで、pollingをしない期間を作るというためにスレッ
ドで制御ができないか試行をしている。(デバイスの処理の関係で、監視が
必要ない期間ができる。)
Q: パケットがたくさん来た場合は改善するだろうが、来ない場合は割り込み
ベースの方が速いはず。この場合に、どの程度性能が落ちるかは数値で出
しておいた方が良いのではないか。
A: 良い場合のベンチマークを意識して出していた。今後は検討したい。
Q: pollingは、割り込みが続きすぎて他の処理ができない問題を解決するとこ
ろにあった。他の処理が進まない問題への対処だったはずなので、複数の
NICを載せてpollingをして嬉しいのか。FreeBSDがNIC毎にしてないのは、
そのためではないか?
A: FreeBSDの実装の動機はあまりよく知らない。ルータとして使用する場合を
想定していたこともある。
I: NIC毎で嬉しい場合はある。制御用のNICとデータ提供用のNICといった運用
もある。
A: NIC以外に利用価値があるか? 0.4で.ifnet構造体に依存しないようにした。
あんまり賢くない電源管理をしている機構?
やっぱり要らんか?
Q: 計測に使ったNICの種類を教えて欲しい。
A: ex: 3C905無印
fxp: interruptを無効にするマイクロコードは持ってない。
rtk: enable/disableを試す程度。
Q: 性能の計測のところでTCPだけだが、ターゲットはTCPだけか。
A: 測定しやすいために、TCPだけだった。
Q: TCPだと(pollingで間に合わないといったために)パケットロスで性能が落
ちるが、そこは調べているか。
A: 測定のやりやすい、という方法で。
bpfでTCPの状態を調べるプログラムを書こうとしている。
Q: delayの出る場合にTCPは遅くなる。測る対象としては不利ではないか。
A: 遅くなるのが、許容範囲なのかそうでないのか調べたかった。
(実は、そのため結果はUDPしか出していない。)
I: TCPの性能を測る場合はnetpipeなどを使うといいかもしれない。
I: 全能力をftpにしたときに速いことを求められているのではなくて、他の仕
事に余力ができたことが求められているので、そちらで比較した方がよい
のではないか。
I: 環境を作るのが難しいかもしれないが、固定したトラフィックを継続して
いて、そこで使用されるCPUタイムなどを比較してはどうか。
I: ツールを作るときにsmart-bitもどきを作っていただけるとみんなが嬉しい
のではないか。(ちょっと劣ってもよいから、簡単に使えるものが欲しい。)
I: smart-bitもどきを作るのに、device pollingがよいのではないか。
I: 人的リソースがない → バグがあろうが無かろうが公開して見せてしまえ
ばよい。
o Citrus iconv Takuya Shiozaki
less presentationからlvにバージョンが上がった。
Citrus iconv
基本的な設計思想
- charcacter set independent
世の中の殆んどはunicdeべったり
フレームワークはunicode
拡張性と柔軟性
プラグインの追加
コードの共用
エンコーディングモジュールをlc_と共有
構成要素の概要
iconvインターフェイスとiconvモジュール
iconvインターフェイスは実質的に何もしていない。
iconv_stdモジュール
ESDB(Encoding scheme database)
CSMapper(文字コードマッパー)
stdenc(標準エンコーディング)
変換ルーチン(iconv(3)
ESDBとは何か
エンコーディング・スキーム
文字列を表現する方法 → EUC
1つのエンコーディングスキームには1以上の文字集合
ESDBの内容
エンコーディングスキームモジュール名
キャラクタセット(ID)とキャラクタセット名の対応表
い文字をCSID+INDEX
存在しない場合の代替え文字
ESDBの例(EUC-JP)
文字集合マッパ─
文字集合の文字を別の文字集合に変換
JIS X 0208の空白文字をUCS (0x2121 -> 0x3000)
今は1:1の変換だけ
APIレベルではN:M変換もサポート
将来はuninodeのcompose/decomposeやcollation
標準エンコーディングインターフェイス
localeのmb*と共用
...
変換ルーチン(iconv(3)相当)
現状
NetBSD 2.0に入るダルお。
主要なエンコーディングはちゃんと動いている。
変換テーブルやESDBのデータが十分でない。
iconv_stdで対応できないもの
Unicodeのcompose/decompse
M:N変換に対応する必要
未知の言語
文字とは何か。
man pageがない
wizd(8)から文句が来た。
結論
CSIなiconvを十分実用的に書けたと思う。
iconvとlocaleまわりの共用化もできた
collation対応への道筋もついいたと思う。
iconv(1)で遊んでみて下さい。
Q: uwe@netbsdが「ロシア(KOI)をどうすればいいんだろう」
A: 1個コミットしてみるといい。
Q: 1文字毎に属性を持っているので、GNU iconvよりも遅いのではないか。
A: 測ってはいないが多分遅いだろう。ベンチマークして、あまりにひどかっ
たら考えたい。
Q: string prepやUnicode 4.0への対応は。
A:
Q: collationが入ってからと思うが、タイやHinduのようなグリフが変ってい
くものへの対応は。
A: 文字ではなくて表示する方の問題ではないのか。(文字とは何?)
I: 文字テーブルの変換をする部分ではないか。
Q: IDN絡みで、pyunicodeとかのサポートは? :-)
A: demoとしてのインパクトは高いと思ってる。今のところはちゃんと対応は
していない。
Q: ドキュメントやmanページの存在は大きいが、どうすればよいか。
A: 参照するためにはposixのドキュメントがある。バックエンドは書かないと
いけない。
I: 全部揃ってからで無くても...。
NetBSDでノートパソコンを使おう Takuya Shiozaki
NEC mobioNX
CASIO FIVA 206VL
素のNetBSDではあまりよく動かない。
Fujitsu LOOX S80C
素のNetBSDではあまりよく動かない。
Q: 電源周りの枠組みが、やっぱりない。
A: ...
I: 5分くらいさわってないと、何かができるといったフレームワークがない。
Q: ThinkPADでのアクセス・コネクト、環境によって、使用するインターフェ
イスを選んだり、といったことをしているが、誰かしてないか。
A: 誰かしてないか、欲しいです。
Q: 電源だけじゃなくて、xxx_ctlやsysctl(8)とかがいっぱいあって、区別が
つきにくい。
A: ldapみたいな仕組みでできたら...。
Q: libevent(3)は関係あるの?
A: select(2)とかを統一しようとしてるので、直接の関係はないのではないか。
NetBSDとGBA(Game Boy Advance)をつないでみる Takuya Shiozaki
デモ
Q: カーネルに手は入ってますか。
A: ugen(4)を使ってるだけです。
Q: つないだ謎のケーブルは何?
A: 複数のゲームボーイをつないでゲームするため。
o developer紹介
21人
47か49人(日本人)
227人(全世界)
- BSD Con CFP
- 来週
BSDなひととき