システムコールを経由する生のLinuxスレッド | POSTD
Linuxのスレッドは、洗練された美しい設計です。スレッドは仮想アドレス空間とファイルディスクリプタテーブルを共有するプロセスに過ぎません。プロセスによって生成されたスレッドは、メイン”スレッドの”親プロセスに追加された子プロセスです。これらは同じプロセス管理のシステムコールを通して処理されるので、スレッドに関するシステムコールのセットを分ける必要性を取り除きます。これはファイルディスクリプタと同様に洗練された方法です。 一般的に、UNIX系のシステムではfork()を使ってプロセスを生成します。新しいプロセスは、オリジナルのコピーとして独自のアドレス空間とファイルディスクリプタテーブルを取得します。（Linuxではコピーオンライトを使用して、この部分を効率的に処理します。）しかし、これは非常に高度なスレッドの生成方法なので、Linuxでは別の clone() システムコールを使用します。
Linuxでロードバランサやキャッシュサーバをマルチコアスケールさせるためのカーネルチューニング - ゆううきブログ
本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を
或るプログラマの一生 » Linux Kernel 3.9 の SO_REUSEPORT
Linux Kernel 3.9 には SO_REUSEPORT が追加されているそうです。SO_REUSEPORT でググると日本語のページの中で一番上に出てくる当blog（2013-06-02現在）としては調査しないわけにはいきません :-) Linux の SO_REUSEPORT は「TCP ソケットを完全重複 bind し、受け付けたコネクションをそれぞれのソケットに適当に割り振る」という機能のようです。これは、BSD の SO_REUSEPORT より機能が「強い」ということです（参考）。SO_REUSEADDR の時もそうですが、同じ名前で違う機能にするのやめてくれないかなぁ… 実験 SO_REUSEPORT が追加されたのは3月10日ごろのようなのですが、既に3か月たっていて Fedora 18 が Kernel 3.9 ベースになっており、試すためにソースコードからビルド
Future OS research directions in CCS
Why Plan 9 is not dead yet And What we can learn from it Ron Minnich Advanced Computing Lab Los Alamos National Lab LA-UR-05-4132 Unix • Simple open/read/write/close with streams of bytes • Resources are named via a visible path • This is such an advanced concept that NT still does not do it (try ls \devices sometime) • It was also extremely controversial Two guys and a computer Early Unix Proces
新208.5日問題 - Systems with Intel® Xeon® Processor E5 hung after upgrade of Red Hat Enterprise Linux 6
Linux の連続稼働時間が 208.5 日を過ぎた段階で突如 Kernel Panic を引き起こすという過激な挙動で2011年の年の瀬に話題となった "旧208.5日問題" ですが、あれから二年が経った今、Linux Kernel 内の bug と Intel Xeon CPU の bug の合わせ技により再度類似の不具合が発生することが分かっています。 旧 208.5 日問題の発生原理に関しては以下の blog が参考になります。 okkyの銀河制圧奇譚 : sched_clock() overflow after 208.5 days in Linux Kernel 追記(2014/1/4) 新208.5日問題の簡易チェックツールを作成しました。よろしければお使い下さい。 tsc_checker - 新208.5日問題簡易チェックツール また、Linux Kernel における時間
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
10GbE時代のネットワークI/O高速化
IBM Developer