Linux Kernel ~ 割り込み処理 ~ - レガシーガジェット研究所
概要 「詳解Linux Kernel」を参考にVersion 2.6.11のコードリーディングをしていく。CPUのアーキテクチャは書籍に沿ってIntelのx86とする。 今回は割り込み処理について見ていく。(*nは参考文献のn番目に対応する) 割り込み処理 例外ではほとんどの場合その例外の発生元となっているカレントプロセスにシグナルを送信することで処理する。例外処理もシグナルを受け取るまでは遅延される。 しかし割り込みの場合には別の無関係なプロセスが動作している際に発生することがあり、単純にカレントプロセスにシグナルを送信するだけではない。 割り込みは大きく3種類に分類される。 I/O割り込み 当該割り込みでは割り込みに対応する動作を決定するために割り込みハンドラからデバイスに対して問い合わせを行う必要がある。 タイマー割り込み ローカルAPICタイマや外部タイマなどが発生させる割り込みで
Linuxカーネルのソースコードを機能とレイヤーで分類して表示してくれる「Linux kernel map」
Linuxのカーネルは膨大な数のソースコードから成り立っており、どこに何の処理が書いてあるのかぱっと見当をつけるのにはかなりコードを読み込む必要があります。「Interactive map of Linux kernel」はそのソースコードを機能とレイヤーで分類して表示してくれるサイトということで、使い勝手を試してみました。 Interactive map of Linux kernel http://www.makelinux.net/kernel_map/ サイトにアクセスし、ロードが終わると下の画像のように6列6行の表が表示されます。列が機能の分類を表しており、「インターフェース」「システム」「処理」「メモリー」「ストレージ」「ネットワーク」という分類になっています。行はレイヤーを表しており、上からシステムコールなどの「ユーザースペースインターフェース」、「バーチャル」、「ブリッジ」
Linux スケジューラーのコア実装とシステムコール - Qiita
はじめに これは Linux Advent Calendar 2016 の第 11 日目の記事です。Linux のタスクスケジューラーのソースコードや関連するドキュメントなどを読んで分かったことをまとめました。とても長いです・・・ はじめにスケジューラーのアーキテクチャと重要な概念を紹介し、その後はスケジューラーコアとシステムコールの実装について分かったことを延々と述べます。調べきれなかったことや分からなかったことは TODO に残したので、コメント欄とかツイッターで教えてもらえると嬉しいです。間違いの指摘も大歓迎です。 ちなみに私が読み始めたきっかけは、スケジューラーのアーキテクチャ、スケジューリングアルゴリズム、スケジューリングアルゴリズムの切り替え方、nice 値やプロセッサアフィニティがスケジューリングに及ぼす影響、プリエンプションの流れ、マルチプロセッサにおけるタスクのロードバラ
Linuxカーネルのコードを読んで勉強になったこと - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Linuxカーネルのコードを読んでて、なるほど〜と思うことはよくあるけど、その中でも特に今までの考え方をぶち壊してくれたのはなんだっけと思ったところ、やっぱりリスト構造かなと言うところ。 c言語でリスト構造を作る場合、一般的な教科書方式だと↓のようにデータとnextポインタは密結合になってると思います。これの場合、struct foobarのポインタをnext要素に使っているので、他の構造体（例えば、struct hogehoge）で同じことをしようとすると、その構造体ではstruct hogehoge *nextというメンバ変数を持つ必要があります。 ヘッド要素はstruct foobarです。 struct foobar { int n; char s[64]; struct foobar *next; }; struct foobar head; Linuxカーネルの場合、データとリ
Linux Insides : カーネル起動プロセス part1 | POSTD
ブートローダからカーネルまで これまでの私の ブログ投稿 を読まれた方はご存じかと思いますが、しばらく前から低水準言語を使うようになりました。Linux用x8664アセンブリ言語プログラミングについても書いています。また、同時にLinuxのソースコードにも触れるようになりました。下層がどのように機能しているのか、コンピュータでプログラムがどのように実行されるのか、どのようにメモリに配置されるのか、カーネルがどのように処理や記憶をするのか、下層でネットワークスタックがどのように動くのかなどなど、多くのことを理解しようと意欲が湧いています。これをきっかけに、 **x8664** 版Linuxカーネルについてシリーズを書いてみようと思いました。 私はプロのカーネルプログラマではないことと、仕事でもカーネルのコードを書いていないことをご了承ください。個人的な趣味です。私は下層で何が起きているのかと
Etsukata blog: FreakOut DSP 入札サーバの CPU 使用率を 30% 削減する Performance Tuning
はじめに 勤務先の FreakOut 社では RTB で広告枠を買い付ける DSP の開発・運用を行っています。RTB とは、インターネット広告のインプレッションが生じる毎に、広告枠の競争入札を行う仕組みです。 DSP とは、 RTB において、競争入札をする側のシステムになります。広告枠/広告を見ている人 に対し、最適な広告を、最適なタイミングで届ける機能を広告主に提供する仕組みです。 FreakOut DSP は最適な広告探索・入札価格調整のため、非常に多くのデータを参照し、沢山の演算処理を行います。広告を見ている人が過去にアクセスした Web ページの情報や検索ワード、さらに 広告がクリックされる予測確率(過去のログから機械学習で算出) などを参照し、入札価格を決定するのです。そのため、DSP で入札を担当するサーバは CPU がボトルネックになっており、台数も数百台に嵩んでいます。
perf + Flame Graphs で Linux カーネル内のボトルネックを特定する - ablog
Linuxでddで1GBのファイルを作成し perf でプロファイリングし、Flame Graph (炎のグラフ？)にして可視化したものです。 Flame Graphs は perf(Linux)、SystemTap(Linux)、DTrace(Solaris、Oracle Linux(UEK)、Mac OS X、FreeBSD)、XPerf.exe(Windows) などでのプロファイリング結果を可視化して最も使われているコードパスを早く正確に特定することができます。実体はプロファイリング結果をグラフ(SVG)に変換する Perl スクリプトです。 下から上に行くほどコールスタックが深く、左から関数名のアルファベット順でソートされています。一番上で横幅が広い関数がCPUを長く使っています。今回は "_aesni_enc1" つまり暗号化がボトルネックになっていることがわかります。 システ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
