NAKAMURA Minoru の日記 (2006年4月)

先月の日記(2006年03月) 今月の日記(2006年04月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita



4/30 (日)

[Work] IA-64/Linux で保護キー機能が動いた

朝から会社に出て先週の残りの IA-64/Linux 改造を進める。 ばんじゃい、動きますた。


4/28 (金)

[CPU][Linux] IA-64/Linux の保護キー機能を

IA-64 の仮想メモリ機構と戯れてすでに一ヶ月が経過。 今日は IA-64/Linux で保護キー(Key Protection)機構を有効に使用と悪戦苦闘。

IA-64 には TLB エントリ毎に 24 ビットの保護キーを取り付けることができる。 仮想メモリアクセスが行われる度に、この TLB の保護キーと CPU 内の PKR レジスタ群(なんと16本もある)が比較され、キーが一致していてかつ PKR レジスタ内の属性ビット(読込禁止・書込禁止・実行禁止)が確認される。 許可が出ればめでたくアクセス可能で、ダメだと CPU 例外が送信されるという機構。

この機能は Processor State Register (PSR) レジスタの pk ビットを 1 にすると有効になるが、IA-64/Linux でこのビットを不用意に立てるとカーネルが沈黙してくれる。 Linux のカーネルは仮想メモリ上に配置されているので、カーネル内(おそらく例外ハンドラ内)で Key Miss フォルトや Key Protection フォルトが起きているのだと予想するが、どうやって確認したものか…

追記:4/29

Linux は論理アドレスを2つに分けて、それぞれカーネルとユーザラントを配置する。 IA-32/Linux の場合には下位3GBがユーザー域となり、上位1GBがシステム領域となる。 システム領域の仮想メモリページ→物理メモリページは全てのプロセスで等しくなっているので、どのプロセスのコンテキストでも特権モードを切り替えるだけでカーネルのコードを実行できる。 言い方を変えるとカーネルは、ユーザプロセスのコンテキストを間借りして実行されている。 最近知ったのだが、こういう OS の構成方法は IBM 370 の OS で確立されたものらしい (IBM 370 の CPU には common segment bit といって露骨な TLB 制御方法が存在する)。

IA-64 は 2^64 の空間を 8 つに分けてそれぞれをリージョンと呼ぶハードウェア機構をもっている。 リージョン0から4がユーザラントに、リージョン5から7がカーネルに使用される。 リージョンには 24 ビットのリージョンIDを持つことができ、64 ビットの論理アドレスを 24 + 61 = 85 ビットの仮想アドレスに拡張される(8本のリージョンレジスタがこの値を記憶している)。 IA-64/Linux はリージョンIDをプロセスの識別子に使っている。 そのため IA-64/Linux ではリージョンレジスタ rr[0] 〜 rr[4] を書き換えることが、メモリコンテキストの切り替えになる。

VRN用途代入される値
0IA-32 エミュレータ用メモリコンテキスト番号 * 8 + 0
1動的ライブラリ用メモリコンテキスト番号 * 8 + 1
2テキスト領域用メモリコンテキスト番号 * 8 + 2
3データ領域用メモリコンテキスト番号 * 8 + 3
4ラージページ用メモリコンテキスト番号 * 8 + 4
5カーネル用5(固定)
6カーネル用6(固定)
7カーネル用7(固定)

保護キーの話に戻ると、TLB に itc、itr 命令で自前でエントリを挿入している場合には 24 ビットの保護キーは自分の自由な値を挿入できる。 しかし IA-64 をショート VHPT 運用をしている場合には、保護キー値はリージョンIDと同じ値が自動挿入される。 16 本の PKR レジスタのうち 8 本がリージョンレジスタと同じ値を維持していれば、IA-64/Linux でも key protection モードを使えるはずなのだ。 それを実現しているつもりではあるのだが、どうしてうまく動かないのだろう。

追々記:4/29

書いているうちに気づいた。 ショート VHPT は保護キーにリージョンIDと同じ値を挿入するけど、itc.i、itc.d、itr.i、itr.d で明示的に挿入した TLB エントリは保護キーの値が 0 になっている。 そこで Key Miss Fault が発生しているんだ。

[Food] ごはん処 大戸屋@新横浜

新横浜のビルで武蔵中原から出張してきて元同僚のグループと再会して一緒に飯を食いにいく。

大戸屋:鶏カツのソース丼
鶏カツのソース丼
大戸屋:焼きキャベツ
焼きキャベツ

4/27 (木)

[Prog] プロセス終了後に取れるプロセス統計情報

高林哲氏のブログ光成滋生氏の日記で、スタックの実行時サイズの確保が話題になっているので、ちょっと雑考を記録しておく。

自分の仕事だと、プログラムが自分で使うメモリ量を常に気になることもあるが、それよりサーバープロセスが呼び出す子プロセスのスタックメモリの使用量が気になることが多い。 子プロセスがスタックオーバーフローで死んだ時に「そうだ」ということが確認したいわけだ。

現行の UNIX だとプロセスのメモリ状況を外部から監視する機構が備わっている。 例えば Linux だとカーネル内の struct mm_structstack_vm フィールドが、スタックメモリ量(ページを割り付けた最大のメモリ量)を覚えていて procfs 下に書き出している。 定期的にポーリングしていれば増加量の傾向は分かるが、スタックオーバフローは突発的に起こるので定時監視では把握が難しい。

そういう場合には SIGCHLD シグナルをハンドリングして、wait 系の API 経由で情報を取得するのが筋だ(Solaris の場合は 2003年9月22日の日記に記述)。 BSD 由来の API wait3/wait4 を使うと、 子プロセスが持っていた struct rusage の情報を取得できる。

struct rusage の構造は以下の通り。 ru_isrss のフィールドにプロセスのスタックが割り当てたメモリ量が記憶されていると期待できる。

struct	rusage {
  struct timeval ru_utime;      /* user time used */
  struct timeval ru_stime;      /* system time used */
  long           ru_maxrss;     /* maximum resident set size */
  long           ru_ixrss;      /* integral shared memory size */
  long           ru_idrss;      /* integral unshared data size */
  long           ru_isrss;      /* integral unshared stack size */
  long           ru_minflt;     /* page reclaims */
  long           ru_majflt;     /* page faults */
  long           ru_nswap;      /* swaps */
  long           ru_inblock;    /* block input operations */
  long           ru_oublock;    /* block output operations */
  long           ru_msgsnd;     /* messages sent */
  long           ru_msgrcv;     /* messages received */
  long           ru_nsignals;   /* signals received */
  long           ru_nvcsw;      /* voluntary context switches */
  long           ru_nivcsw;     /* involuntary */
};

ただし問題があってほとんどの UNIX 系 OS では rusage 構造体の一部のフィールドしかサポートしていなくて、メモリ量関連のフィールドをサポートしている UNIX は (Linux も含めて) ほとんどない。 よって rusage はスタックサイズの取得として使えない。 南無三。

覚え書き

家賃を払ったよ。

コメントを書き込む
[akr] 2006-04-29 13:23:49
ru_isrss がサポートされていたとしてもそれは最大値でないところがさらに使えない...
[nminoru] 2006-04-29 14:50:37
akr さんはじめまして。
クラッシュ原因を探るという意味ではプロセス終了時のメモリサイズ値が分かるのは貴重ですが、いかんせん resident set memory サイズだと確かにスタックの状況はほとんど分かりませんな。
プロセス終了 → wait の間にもう少し広い範囲のプロセス統計情報を取得できるといいですけどね。wait5 ?
[akr] 2006-04-29 15:45:42
私の理解では、プロセス終了時の値でもないと思います。
どうもこれは integral というくらいで積分した値のようなのです。
たとえば、GNU time では実行時間で割って平均値を出しています。

もっとましな情報が欲しいというのはたしかにそう思います。

[nminoru] 2006-04-29 19:31:01
``integral\'\' はマップしたメモリページの累積だと思っていたのですが、そうではなかったんですね。
FreeBSD ではまだ維持しているようで
http://fxr.watson.org/fxr/source/kern/kern_clock.c?v=DFBSD#L489
たしかに定期的に値を足しています。こっちとしては欲しいのは vm->vm_ssize の方です。

4/25 (火)

[MyWeb] 掲示板へのスパムの対処方法

よそ様の掲示板やコメント欄にスパム書き込みが大挙して押し寄せるのを傍観していたが、うちの掲示板にもようやくスパム書き込みが来るようになった。

今のところ IP アドレスは固定・特殊な user-agent を名乗るという初歩的なツールを使ったもののようだ。 特徴的なアクセスの POST だけを禁止しているが、何度かアクセス条件を弾くうちに少しづつツールが進化しているように見える。 うちの掲示板は Mini BBS EX をカスタマイズして使っているのだが、最初はそのカスタマイズした部分に対応していなかったのが、今は対応するようになった。

余所のサイトでも個別に対処して禁止事項を増やしていくと、スパマー側も少しづつ対処してくるというイタチごっこが行われるらしい。 ではスパムを手動で削除しているとスパマーはいつまでも同じ戦略を取り続けるだろうか?

掲示板側に細工をして、スパマーと特定できるサイトからの書き込みは単純に弾かずに、スパムサイトからのみ閲覧可能にしておく(他の一般サイトからはコメントが見えない)とどうなるのだろう? 無為に投稿し続けてくれるだろうか。 G.W. 中にやってみよう。

追記:4/30

投稿毎にスパムコメントかどうかのチェックをしておき、一般の閲覧ではスパムが見えないようにしておく。 スパムメールを投稿するとスパムメール投稿フラグを立てたクッキーを送り込んで、掲示板中のスパムメールが見えるようになるという仕組みを実装してみた。

うまく引っ掛かってくれるかどうか!?

コメントを書き込む
[ぶぅ] 2006-04-26 10:10:24
それ (・∀・)イイ!

ここに書いちゃったから特許に出来ないね
[nminoru] 2006-04-27 01:01:06
> ここに書いちゃったから特許に出来ないね
あぁ。その手があったんだ (T_T)

4/24 (月)

[Linux] Linux module のバージョンチェック

Linux カーネルとモジュールのバージョンチェック機構をよく理解していないのだが、カーネルに修正を加えてリコンパイルした時に既にバイナリ化されたモジュールとの整合性を保ち続けるにはどうすればいいのだろうか?

  • Release name ... これはカーネルの suffix
  • Version magic ... この機構は良く分からん。
  • Module versioning ... CONFIG_MODVERSIONS をつけてビルドした場合、kernel 側の export symbol 毎(?)に CRC のタグが付き、モジュールがロード時にチェックする。

構造体の形が変わった時などにも埋め込まれているバージョン番号を古い値で留め置きたいのだが、さてどうしたものか。

コメントを書き込む
[しゅ] 2006-04-25 11:02:37
バージョンチェックをする/しない、っていうカーネル側の(コンパイル時)オプションがありませんでしたっけ。
[nminoru] 2006-04-26 00:22:17
CONFIG_MODVERSIONS ですね。
これをオフにしてビルドすれば何となくいけそう気がしますが、でもそうなると module versioning は全部オフになってしまいそうです。
欲しいのは Java のストリーム固有識別子 (http://java.sun.com/j2se/1.5.0/ja/docs/ja/guide/serialization/spec/class.html#4100)みたいな解なんですが、うまいハックを調査中です。
[nminoru] 2006-05-01 19:24:14
CONFIG_MODVERSIONS だけでは駄目で CONFIG_MODULE_SIG も必要でした。この二つを外してビルドしたカーネルはモジュールのシグネチャとバージョンのチェックをしなくなるようです。

4/22 (土)

風邪をひいたみたい

今週の頭から身体が妙にけだるかったのだが、朝方から咳が出るようになる。 風邪をひいたみたい。

通勤が電車になったのが不味かったのか、職場の人口密度が上がったのが不味かったのか、どちらにせよ注意が足らなかった。


4/21 (金)

[Work] アーキテクチャの進化とメインフレーム

IBM System/370 系の勉強を続けている。 System/370 とその後続のアーキテクチャは商業計算機としては初めてキャッシュや仮想記憶を導入したりとコンピュータアーキテクチャの進化の歴史がある。 だが時代の徒花としか思えない機構も多くて「どうしてこういうアイデアを出したのか?」とアーキテクトを小一時間問い詰めたい、問い詰めたい、けどジーン・アムダールはもう死んでいる。

Storage Key
物理メモリには 2K バイトのページ(後に 4KB に拡張)が区切られており、そのストレージページに対して 7 ビットの特殊なタグ情報がついている。 AS/400 もそうだが、IBM は「物理メモリにタグ」という概念が好きなようだ。
ACC (4bits)F (1bit)R (1bit)C (1bit)
Rereference/Change Recording
ストレージページに参照アクセスがあった場合 R ビットが自動的に 1 が、書込アクセスがあった場合には C ビットが自動的に 1 が立つ。 参照履歴やページのダーティ管理ができるという仕組み。
Key-Controlled Protection
ページに対する書き込みが行われる場合、ストレージキーの ACC (Access Controlled) ビットと CPU 内にあるキーが照合され、一致しない場合には書き込みができない。 CPU 内の状態によっては Key-Controlled Protection は無効になる。
Fetch Protection
F ビットが有効な場合には、Key-Controlled Protection が読み込みに対してもはたらく。
主に仮想メモリを実現するためのものだが、仮想メモリはこういう物理メモリタグがなくてもできる・その方が効率がいいということが分かる前の機構だ。 とはいえそれほどセンスが悪いわけではない。
プロセッサ固有領域
実メモリアドレスの 0-511 はプロセッサが固有情報を読み書きし、割り込み制御等に用いている。
System/370 の癌はここに発している。
Prefixing
実メモリの低位アドレスにはプロセッサが固有情報を書き出すと決めてしまったものだから、マルチプロセッサ時に問題が生じる。 そこでマルチプロセッサ時には、プロセッサによって実メモリの最初の 2K バイト領域の実体を、物理メモリの別の場所にある 2K バイトと入れ替えられるという機構を作った(2K バイトは後に 4K バイトに拡張される)。 これが prefixing。 入れ替えるアドレスは prefix レジスタで決定できる。
後智恵で言えば「prefix レジスタが指す物理アドレスにプロセッサ固有情報を書き出す」と決めればよかったのだが後の祭り。
Low Address Protection
プロセッサ固有領域の情報を迂闊に書き換えられてはたまらない。 メモリアクセス命令の発行するメモリアドレスが 2048 よりも小さい場合 には 書込み保護がはたらく。
アンダーラインを引いたのには理由があって、実メモリの 0-2047 に掛かる保護機構ではないのだ。 仮想記憶が有効な場合には、仮想アドレスの 0-2047 バイトも書き込み禁止になる(その先にどんな実メモリがマップされていても)。 逆に実メモリの 0-2047 を含むページを仮想メモリの 1 ページ目以外に割り付けると Low Address Protection ははたらかないって、これでいいのか?

ストレージページの概念は 2K → 4K に拡張されたが、Low Address Protection は 0-2047 バイトのままだった。

(追記:2006.9.2)
Fetch-Protection Override とぐっちゃにしていた。 Low-Address Protection の範囲は 0-511 だけ。
Fetch-Protection Override
Key-controlled Protection & Fetch Protection によって読み込み保護が行われているのだが、0-2047 の領域に行われている Fetch Protection を部分的に解除できるという機能。
それならば最初の1ページの F ビットを立てない運用をすればいいのに…
Supression-On-Protection
Low Address Protection に反して、実アドレスの 147 バイトの 5 ビット目に対しては書き込みができる(このビットは割り込みの終了の仕方を決めるビット)。 そういう制御はレジスタでやれよ…

(追記 2006.4.28)
プログラマブルに書き換えられる機能ではないようだ。

他にも仮想メモリ空間が primary-space-mode と secondary-space-mode と二つ持てるというところまではいいのだが、home-space-mode(三番目の仮想メモリ空間)、access-register-mode (メタ仮想メモリ空間を作れる機構。実質無限の仮想メモリ空間を作れる。)とかがある。 仮想メモリ→物理メモリ以外にも CPU が行うページテーブル検索機構が ASN 変換、AR 変換、PC番号変換と 3 つもある。

思うに System/370 系は、何でもハードウェアで解決しようとしたアーキテクチャの極北なんだろうな。 で、その反対側に Alpha アーキテクチャがあると。


4/20 (木)

[Food] みちのく たち花@新横浜

新横浜駅のショッピングモール ASTY の中にあるそば・うどんの店だが、微妙に秋田料理がある。

きりたんぽ
きりたんぽ
うま〜
ヘルシー天丼
ヘルシー天丼
野菜だけの天丼

4/19 (水)

[Food] 地鶏や五右衛門@新横浜 (公式ドコ割)

昼飯に「地鶏の親子丼」を食べる。


4/17 (月)

Guy L. Steele Jr. が来るよ

4月27日(木) 15:30 に東大本郷キャンパス(理学部7号館214号室) に Guy L. Steele Jr. が来て講演するそうだ。 演目は Parallel Programming and Parallel Abstractions in Fortress。 聞きには行きたいが無理っぽい。

[Java] 最近の Java VM

IBM と BEA がマイナーバージョンアップしていた。

ところで SEPCjbb2005 の現在のトップスコアは SGI の 128-way Itanium2 上で計測された BEA JRocktit 5.0 R26.0.0-34 なんだけど、 オプション表 に載っていない 隠しオプションがワラワラ使われているようだ。

  • -XXcompressedRefs
  • -XXlazyUnlocking
  • -XXtlasize512k
  • -XXgcthreads2
  • -XXoptthreads2

[Food] 揚州商人@新横浜 (公式?)

酸辣湯麺(スーラータンメン)。 酸っぱいがそれほど唐辛子くさくない。 むしろ胡椒で辛い。


4/16 (日)

[Book] Solaris Internals 2nd が発売

Richard McDougall と Jim Mauro の Solaris Internals の 2nd Edition が Amazon から購入可能になった。

2nd Edition の Table of Contents が ここからダウンロード可能。 1st Edition と構成はずいぶん変わっていて、Solaris9 から加わった MPSS や、Solaris10 の新機能である Zones や DTrace の解説が加わっているのが嬉しいところ。

参考

6時だというのに

外が明るいのに驚く。 冬も終わったか。


4/15 (土)

アフェリエイトの収入報告

しばらくサボっていたけど、前回(2005年4月10日の日記)からのアフェリエイトの収入は以下のとおり。

日時Google楽天Amazon.co.jp
2005/04US $15.18300円 
2005/05US $15.65248円 
2005/06US $21.130円 
2006年 2QUS $51.96548円2,266円
2005/07US $21.290円 
2005/08US $21.09100円 
2005/09US $17.71375円 
2006年 3QUS $60.09475円1,639円
2005/10US $15.000円 
2005/11US $24.55260円 
2005/12US $32.34198円 
2006年 4QUS $60.09458円1,869円
2006/01US $19.064,519円 
2006/02US $28.48336円 
2006/03US $20.651,032円 
2006年 1QUS $69.205,887円1,806円

このサイト経由で購入 &アクセスしてくれた人に感謝です m(_ _)m


4/14 (金)

[Food] 釜あげのスパゲッティー 洋麺屋 五右衛門 新横浜店 (ドコ割)

横浜アリーナの隣にある「釜あげのスパゲッティー 洋麺屋 五右衛門 新横浜店」へ行ってみました。 一見すると蕎麦屋のような構えなのだが、実はスパゲッティー屋。 和風の皿の中にパスタが出てきて、箸で食べるというスタイル。

カルボナーラを食べるが麺はちょっと固めに茹で、釜ゆでということもありどこなくソーメンを連想させる。 お値段は 1,050 円と高めだがボリュームはある。

写真は撮り忘れてしまった…


4/13 (木)

[Bench] Opteron が SPECint2000 で 2,000 越え

定期の CPU2000 ウォッチ。 スコアは上段が peak スコアで、下段が base スコア。

Opteron 256 (3000MHz) が SPECint2000 で 2,000 を初突破。
コンパイラの改善もあるが、Opteron は (少なくとも Linux 環境では) 32-bit 互換モードよりも 64-bit モードで使う方が高速というのが確立しつつある。

POWER5+ の浮動少数計算はあいかわらず爆速で、他を寄せつけない。

Sun からはほとんど敢闘賞ものの UltraSPARC IIIi のスコアが公開された。 1600MHz にはなったものの性能はしょぼしょぼ。 UltraSPARC T1 のスコアはどうなるんだろう。

ファミリープロセッサCINT2000CFP2000コメント
x86-64AMD Opteron 256 (3000MHz)2024
1784
2021
1853
Windows(32-bit)環境で測定
AMD Opteron 256 (3000MHz)2043
1821
2365
2122
Linux環境で測定
x86Intel Xeon 5080 (3730MHz)1771
1764
Windows 環境 + ICC
Intel Pentium Exterme Edition 965 (3733MHz)1828
1831
2108
2104
Windows 環境 + ICC
int の base と peak がひっくり返っている。最適化しない方が速いとは…
POWER
PowerPC
IBM POWER5+ (2200MHz)1765
1705
3513
3271
AIX 5L V5.3 + IBM XL Compilers
IBM POWER5+ (1900MHz)1536
1479
3048
2850
AIX 5L V5.3 + IBM XL Compilers
IBM PowerPC 970MP (2700MHz)1706
1623
2259
2060
AIX 5L V5.3 + IBM XL Compilers
SPARCSun UltraSPARC IIIi (1600MHz)872
779
1365
1284
Solaris 10 + Sun Studio 11

[Food] ジャイアントプリッツ 江戸むらさき

グリコの地域限定プリッツの 東京・横浜地区限定商品。 桃屋の「江戸むらさき」を練り込んでしまったようだ。

目隠しをして臭いを嗅がされると、「ごはんですよ!」と区別がつかないかも。


4/12 (水)

[CPU] 仮想メモリのアドレスの区切り方

仮想メモリの話が続くが MMU がハードウェアでページテーブルを検索するプロセッサの場合、仮想アドレスをビットで区切って格段のディレクトリテーブルのインデックスにすることになる。 x86 の場合は2段のページテーブル構成で 10 bits : 10 bits : 12 bitsに、x86-64 の場合も4段のページテーブル構成で 9 bits : 9 bits : 9 bits : 9 bits : 12 bits に分ける。

この仮想アドレスの区切り方のうち、最下位の 12 ビットはページテーブルの大きさ(4K=2^12)が反映されている。 それ以外の VPN 部分の区切り方は恣意的だと思っていたが、よ〜く考えると各段のディレクトリテーブルの大きさが基本ページ 1 枚に収まるようにできているようだ。

  • 32 ビット CPU の x86 の場合は基本ページサイズは 4 KB/page。 仮想ページ1枚に対して 32 ビット = 4 バイト = 2^2 の大きさのページテーブルエントリ(PTE) を持っているが、 それが 2^10 個集まると 2^(10+2) で 2^12 になりちょうど 4KB になる。
  • 64 ビット CPU の x86-64 の場合も基本ページサイズは 4KB/page。 仮想ページ1枚に対して PTE の大きさが 64 ビット = 8 バイト = 2^3 になり、 2^9 個集まると 2^(9+3) = 2^12 でちょうど 4KB になる。

Linux のソースを読むと、MMU がソフトウェアでページテーブルを検索するプロセッサでも、この区切り方はディレクトリテーブルが基本ページサイズに納まるように作ってある。 IA-64/Linux の場合は 16KB/page (=2^14) が基本で、PTE の大きさが 8 バイト = 2^3 必要になるので 3 段のページテーブルで 11 bits : 11 bits : 11 bits : 14 bits に区切っている。 Itanium2 は論理アドレス長が 64 ビットだけど、この設定では 11 * 3 + 14 = 47 ビット までしか使えない。 ページテーブルを 4 段化するマクロ(CONFIG_PGTABLE_4) が入っていて、これを有効にしてリビルドすると 11 bits : 11 bits : 11 bits : 11 bits : 14 bits で 11 * 4 + 14 = 58 ビット ビットまで使えるようになるが、限界までは 6 ビット足らず。

x86-64 の場合、今は 4 段のページテーブルだけど 9 * 4 + 12 = 48 ビットまでしか扱えない。 ページテーブル段数を上げて仮想メモリ空間を網羅しようとすると 7 bit : 9 bit : 9 bit : 9 bit : 9 bit : 9 bit : 12 bit で、5 段半のページテーブルが必要か…


4/11 (火)

[CPU] UltraSPARC の Translation Storage Buffer

「仮想メモリ方式の分類」の SPARC V9 の項 に書いた Translation Storage Buffer(TSB) だが、TLB ミスが起きた時に(例外を起こさずに)ハードウェアが自動的に充填してくれる機構と信じていたのだが、そうではないようだ。 Solaris Internals をよく読むと、少なくとも UltraSPARC I・II では TLB ミス例外が起きて、その例外ハンドラの中で TSB からデータを拾って TLB を挿入する必要がある。 つまりソフトウェア制御。

[Food] みんみん@新横浜

新横浜国際ホテルの「みんみん」(漢字が出ない) でジャージャー麺の日替わり定食。


4/10 (月)

[Food] パキスタンレストラン マルハバ@池袋

愛媛県警に勤めている友人が上京してきた。 昨年までは別部署にいたが、今年度から人事部に移ったそうだ(3年ぐらいごとに配属が替わるらしい)。

今回はリクルータ活動のための上京で、今日から3日かけて都内の大学 14 を巡るそうだ。 ご苦労様。 今日は文京区の比較的密集した地域の大学を5つ、明日は豊島区・新宿区の大学を、最終日は八王子市と府中市の大学を訪ねた後に羽田からフライトするそうな。 最終日だけ強行日程になりそうね。

E県警はキンタマウィルスの流出で大騒ぎになったそうだが、「現場のパソコンの支給が急に強化されて、私物パソコンを持ち込まなくても良くなった」そうだ。

二人で池袋にあるパキスタン料理の店マルハバで飯を食べた後、ジュンク堂に寄って都内の地図を買ってから別れる。

マルハバ:店の前
店の前
マルハバ:マトン、魚、チキンとホウレン草のカレー
マトン、魚、チキン とホウレン草のカレー(左から)

4/9 (日)

髪を切る

元住吉の1,050円均一の散髪屋で髪を切る。
QB のような「10分の身だしなみ」といった店なのだが、今日は場違いに若い女性が理容イスに座っている。 複雑な髪形をしていて、私の番が来る10分前から切り始めているようなのに、私が髪を切り終わった後も始末がついてないようだ。
素直に美容院に行けばいいのに…

コメントを書き込む
[本店] 2006-04-14 01:51:51
私もいい加減髪の毛を切りに行かねば、、、
メリケンで切るとどうなるかこうご期待!!
[nminoru] 2006-04-15 00:38:39
せっかくカルフォルニアにいるのですから、
ヒッピーのように髪を伸ばすという手もあります。
# アメリカ西海岸に対する認識が30年ぐらい古い?

4/7 (金)

[Prog][Linux] Linux のスレッドアフィニティ

  1. IBM developerWorks | プロセッサー・アフィニティの管理

Linux で NPTL(Native Posix Thread Library) を使っている場合、pthread_attr_setaffinity_np を使うことでスレッド生成時にアフィニティを設定し、pthread_setaffinity_np_func を使うことで生成後のスレッドにアフィニティを再設定できる。 これは

ただ 1. の文献によれば、sched_setaffinity(2) によってスレッドのアフィニィも変更できるとある。 意味的にいって sched_setaffinity はプロセスのアフィニティをセットして欲しいのだが、実質的には Linux の場合プロセスとスレッドが非常に近いので、スレッドの指定ができてしまうようだ。 sched_setaffinity で、スレッドアフィニティを指定する場合は、変更したいスレッドで第一引数を 0 にして実行するか、gettid の結果を第一引数に渡す必要がある。

#include <sys/syscall.h>

pid_t tid = syscall(SYS_gettid);

4/4 (火)

クマの○ーさんの AA ?

何かを吹いているように見えるが…

           ◤◥◣  
 ▂ ◢◤▀〓▲▂▐      ∵▂ ▪ ▄▆■▀〓◣▬ ▪ .
▌ ▼     ◥◣▼       .▂▅■▀ ▪ ■▂¨ ∵▪ ・
▀▍ ◢◤     ▅ ▐◣   ◢◤ ◢■▀  ▄▆▇■〓…▄
  ▍  ▅ ◢■     ▍ ■ ▂▅██▆▇■〓▀ ◥◣ ∴ ▪ .
 ▌   ▂   ▐◣ ▐▅▇■██■▀ ▪ ∴ ….▅ ■  ◥◣
 ▀◣▂  ▀◥▅▆▇■▀▀█■〓▃▂ ▪ ■ ▄▂
    ◥◣▄▂▄▅▀   ∵■ ¨ ▀■▀▀ ▪ ■ ∴‥

[Prog] 実行時リンカーの調査 (2)

だいぶ時間が空いてしまっているが2004年10月22日の日記の続き(発端は 2004年2月16日)。

あれからボチボチ考えていたのだが UNIX の API フックを行うには PLT や GOT を書き換えてもダメだ。 すでに解決されたシンボルテーブルは処理できても、これから解決されるシンボルはどうにもならないからだ。

できればシンボルが解決される瞬間にフックをかけたいと思うと、ld.so そのものにパッチを当てなければならない。 Linux/glibc だと $(glibc)/elf/dl-lookup.c あたりがターゲットのようだ。 実現方法を検討。


4/3 (月)

春一番

今日から新年度。

通りは春一番の強風が吹き抜ける中、パリッとした背広を着た新入社員が歩いている。

まあ、そのパリッと感はお大事に。

[Work] お下がりパソコン

大規模な人事異動に伴って遊休・廃棄されるパソコンが出てくるのゲットして、自分の Linux マシン (VineLinux 3.2) 用のハードをパワーアップ。 これまで RWCP の払い下げマシン(Pentium2 266MHz) → Pentium3 (600MHz) と来て、いきなり 2-way Opteron 250 (2.4GB/L2:1MB) に昇格。


4/2 (日)

[Work] 明日から所属と勤務先が変更

昨日付けで所属と勤務先が武蔵中原から新横浜に変るよ。 今日は職場においてあった私物を取りに行く。 JavaOne でもらったバックパックとか、 机の上に飾っていたフィギュアの類を持って帰る。

明日は武蔵中原に「出張」の予定。


4/1 (土)

スパムメールからウィルス

ウィルススキャンがバックアップアーカイブからウィルスを検出して、 勝手にファイルを移動をしていたことに気づく。 何度も防疫されると面倒なので、 メール類からウィルスの除去をすることにした。

ウィルスは手持ちの4万件近いスパムメールに混在している。 338 通のメールから 433 個のウィルスが発見される。 種類は全20種類とちょっと少ないかも。

2000年ぐらいまでに30種類のウィルスを集めたことがある。 当時はウィルスも今ほどは大量に送られて来なかったので 他の人から貰ったりして苦労して集めた(その後、破棄したが)。 最近はウィルスは亜種が多いので、 集める気になればすぐに集まるようだ。

カウントウィルス名
144WORM_NETSKY.Q
144PE_LOVGATE.AD
72HTML_Netsky.P
23WORM_NETSKY.P
12WORM_BAGLE.AT
9WORM_MYTOB.LZ
9WORM_KLEZ.E
5WORM_NETSKY.D
2WORM_NAVIDAD.A
2WORM_BUGBEAR.A
2WORM_BADTRANS.B
1ECX
1WORM_SOBIG.A
1WORM_MYPARTY.A
1WORM_KLEZ.H
1WORM_HYBRIS.B
1TROJ_BAGLE.AH
1JS_NIMDA.A
1JS_CBASE.EXP1
1HTML_IFRMEXP.GEN

先月の日記(2006年03月) 今月の日記(2006年04月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita


Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp