listen backlog 【3.6】 - Linuxカーネルメモ
(*1) backlog(512)はtcp_max_syn_backlog(400)より大きいので、400を切り上げた512がsyn backlogのサイズになる。 syn backlogのサイズを大きくしようとするには、以下の点に注意する。 (a) net.ipv4.tcp_max_syn_backlogを大きくする (b) listen()で指定するbacklog値を大きくする(apacheならListenBackLogディレクティブで指定できる) (c) backlogの値自体はnet.core.somaxconnに切り詰められるため、net.core.somaxconnの方も大きくしておく。 syn backlogの最大サイズはbacklogサイズに基づいて決まるため、net.ipv4.tcp_max_syn_backlogを大きくするだけでなく、backlog自体が大きくなるよう
第30回 Linuxカーネルのコンテナ機能［8］― cgroupのpidsサブシステム | gihyo.jp
今年も年末を迎えて、Advent Calendarの季節になり、いろいろなカレンダーの案内をみかけるようになりました。 昨年のこの時期に書いた第16回は、Linux Advent Calendar 2014の16日目の記事として書きました。連載記事を直接Advent Calendarに参加させるということが新鮮だったのか、うれしい反応をいただきました。 今年同じことをやっても新鮮味にはかけると思いますが、今年も今回の記事をLinux Advent Calendar 2015の15日目の記事としても書きました。 Linux Advent Calendarということで、前回の最後に「引き続きLXC 1.1の新機能や変更点を紹介」と書きましたが、今回は予定を変更してLinuxカーネルに新たに導入されたコンテナ関連の機能について書きたいと思います。 cgroup この連載では、cgroupについて
Linux/Reading the Linux Kernel Sources - Wikiversity
Part of an ongoing Linux Kernel exploration by SVLUG - the Silicon Valley Linux Users Group You might enjoy our first YouTube video! Good places to follow along: surfing the sources http://lxr.linux.no - browse the linux source code Tamacom Kernel Source Tour Look out for this: sometimes code gets moved from one file or one directory to another.... or converted from raw assembler (in the arch area
【linux】カーネルパニックの種類 | 発生方法 | 対処
1. カーネルパニックとは カーネルパニックとは、カーネルで致命的なエラーが発生し、OSの稼動が完全に停止した状態の事を言います。OSを継続して稼動さえることは不可能であり、再起動するしかありません。エラーの原因を調査するために、カーネルパニック時にはメモリダンプ(カーネルダンプ、クラッシュダンプ、コアなどと呼ぶ場合も有ります)を出力することが可能です。メモリダンプとは実メモリの内容をファイルに出力する機能のことを言います。OSがsyslog (シスログ) に書き出す余裕もなくクラッシュするのでメモリダンプは唯一の解析の手がかりとなることもあります。OSを再起動すると、メモリダンプが /var/crash/<IP アドレス-YYYY-MM-DD-mm:ss>/vmcore にコピーされます。(diskdumpの場合) 参考：diskdumpの設定方法 2. カーネルパニックの種類 カーネル
process-book
この文書はなんですか？ この文書は*nix系のシステムにおけるプロセスやシグナルなどについて説明することを目的に書かれました。「プロセスとかよくわかってないからちゃんと知りたいな」みたいなひとたちが想定読者です。 書いているあいだは gist で管理されていたのですが、ボリュームが大きくなったので github で管理するように変えました。 目次 導入 プロセスの生成 プロセスとファイル入出力 ファイルディスクリプタ preforkサーバーを作ってみよう ゾンビプロセスと孤児プロセス シグナルとkill プロセスグループとフォアグランドプロセス epub と pdf epub化したもの、pdf化したものが release ディレクトリに入っています。thanks to mitukiii & moznion！ ライセンス この 作品 は クリエイティブ・コモンズ 表示 - 継承 3.0 非移
Linuxカーネルに関する技術ドキュメント「Linux internals」の第2部が公開される | ソフトアンテナ
Linuxハッカーを目指す技術者に役立ちそうな技術ドキュメント「Linux internals」の第2部が公開されています(Hacker News)。これは前回紹介した第1部の続編となるドキュメントで、カーネルのセットアップが完了し、アセンブラ言語からC言語のmain関数がよびだされた後、を解説するものとなっています。 具体的には、プロテクトモード、起動パラメーターのzeropageへのコピー、コンソールの初期化、ヒープの初期化、CPUの検証、メモリの検出、キーボードの検出、Querying(様々な情報の取得)などのトピック関して解説されています。 次回第3部は、ビデオモードの設定と、その他プロテクトモードへ移行する前に行う各種準備、プロテクトモードへの移行を解説する予定となっています。
Etsukata blog: Docker を支える Linux Kernel の機能 (概要編)
はじめに Docker はコンテナ型仮想化技術を使ってOSレベル仮想化を実現するコンテナ管理ソフトウェアです。類似のコンテナ管理ソフトとしては、Docker の他にも libvirt、 lxc-tools などがありますが、 Docker には以下の大きな特徴があります。 Infrastructure as Code の思想に基づき、コンテナをコード(Dockerfile) で管理できる docker index で、コンテナイメージを手軽に取得、共有できる Docker は上記のような特徴を持つため、アプリケーションのポータビリティを大きく向上させることができると期待されています。 参考：Naoya Ito 氏 "Dockerアプリケーションのポータビリティを考える" 大変便利な Docker ですが、Docker によるコンテナ管理は、実は数多くの Linux Kernel の機能に
第8回「カーネルパラメーターチューニングノススメ」 | 株式会社NTTデータ先端技術
Tweet 今回は、システムがデッドロックしたり無応答状態に陥ったりしているかもしれない状況を警告する watchdog 系パラメーターについて紹介します。 死活監視ソフトウェアの設定にもよりますが、例えば Pacemaker では、 2 秒間隔で /dev/watchdog への書き込みを行いながら、10秒間（実際には余裕を見て11秒間）書き込みが行われなかった場合に、 /dev/watchdog 発動による再起動が行われる設定になっていることが多いようです。 近年では搭載メモリーが増えてきたことにより、メモリー回収処理が発生した場合の遅延時間も長くなってきるのではないかと思われます。また、仮想化環境では十分な CPU 時間が割り当てられなかったことで処理が遅延し、 /dev/watchdog 発動による再起動が発生しやすくなっているようにも思われます。もしかすると、 10 秒という /
iostat はどのように %util を算出しているか(3) - ablog
iostat はどのように %util を算出しているか - ablog http://d.hatena.ne.jp/yohei-a/20130925/1380070554 と続いた iostat から Linux Kernel のブロックレイヤーへの旅は Etsukata blog: iostat -x の出力を Linux Kernel ソースコードから理解する のおかげでほぼ終わりを迎えました。 part_round_stats() では、その延長で、全てのリクエストがキューにいた時間の積算値を表すtime_in_queue と、デバイスがIOリクエストを発行していた時間を表す io_ticks を更新しています。io_ticksには前回のリクエスト完了から、今回のリクエスト完了までを加算し、time_in_queueにはそれに実行中のリクエスト数を掛けたものを加算しているのがわかり
カーネルハッカー・小崎資広の「コードを読む技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第2回（毎週火曜日に掲載、これまでの連載一覧）。「WEB+DB PRESS Vol.80」（2014年4月24日発売）に執筆した「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第1弾は、富士通のエンジニアとしてLinuxカーネルの開発に参加されている小崎資広さんです。 Linuxカーネルは、ソースファイルだけで3万5000個以上、行数にして1500万行を超える、巨大ソフトウェアです。小崎さんが、どうやってこの巨大なソースコードと戦っているかは、きっと「エンジニアの学び方」の参考になるはずです。
The Linux Kernel: Table of Contents
David A Rusling 3 Foxglove Close, Wokingham, Berkshire RG41 3NF, United Kingdom
Linux:sparse fileのファイルサイズと実際に使っている領域の大きさはどう調べるのか。 - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
今日の原書で学ぶ64bitアセンブラ入門(6)でsparse fileの話題が出て気になったので調べてみた。何を調べたかったかというと、sparse file全体の大きさ、実際に使っているサイズはどう管理されているのかというところ。 ちなみに、Sparse FileについてはSparse Fileとは？とか、Arch Linuxのwikiが作り方、サイズの調べ方など充実います。 まず、sparse fileを作ってその時点でのサイズを見てみます。 ddでinputとして/dev/zeroを、outputにfile.imgを指定します。そして、seekで10MiB目に移動してますがデータそのものはcount=0を指定しているので書き込みしません。 そうすると読み込みバイト数0、書き込みバイト数0という感じで処理が終わります。 masami@saga:~/sparse_file_test$ d
Linuxのpipeの実装を見てみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
Unix V6のpipe()と比べてLinuxのpipe()どう実装しているんですかねーなんて話を最近したのでちょっと見比べてみた。 V6のpipeははじめてのOSコードリーディング 読書会 (15)でやったところなんだけど、俺は風邪ひいて家で引きこもってたので・・・ V6のpipeの挙動は大体こんな感じ。 pipeはルートディスクのストレージ領域を4096B（8ブロック）使用し実現する 4KBのデータ領域はひとつのファイルとして扱われる（inodeが割り当てられる） オンメモリではなくてストレージを経由するが、バッファサイズが小さいのでブロックデバイスのバッファキャッシュが効きやすいようになっている pipeの受け手がデータを読みだす前に他の優先度の高いプロセスがブロックデバイスを使用するとキャッシュが効かなくなる可能性あり でも、データはストレージに書かれているので内容が壊れると言った
Linuxのネットワークインターフェース名って何を基準に決めてるのかを確認してみる - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
そういえば何を基準にインターフェース名を決めてんだっけ？というのを確認してみる。名前をつけているのはudevというか今ならsystemdですかね。とにかくそのルールが知りたかったのです。 うちのデスクトップのイーサネットカードだとこんな感じのインターフェース名になっている。 masami@saga:~$ ip addr 2: enp101s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 そこでググってみるとArch LinuxのMLからudev-builtin-net_id.cというものに辿り着く。 これがインターフェース名を決めているコードっぽいけど、コメントにルールが書かれているのでそちらを見てみると以下のような記述が。 * Two chara
カーネル／VM探検隊
目的 カーネルや仮想マシンなどを代表とした、低レイヤーな話題でわいわい盛り上がるマニアックな勉強会です。 低レイヤー技術を勉強している人達の交流の場に出来ればと思います。内容 Linux・*BSD・Plan9・Windowsなどの各種OSのデベロッパー／ヘビーユーザー、セキュリティ界隈の方々、競技プログラミング方面や難読化プログラミングが趣味な方、VMMの研究者の方、社宅でBGP組みたい方、などなど様々な分野で御活躍中の方々に幅広くご参加頂いております。 発表内容は参加者の人種に偏りがありますので若干OS・VMM・ハードウェア・プログラミング言語などの話題に偏りがちですが、一応ノージャンルという事で、楽しければなんでもOK！というスタンスです。 是非貴方も発表しに来て下さい。 初参加なのでまずはLTをやってみよう！というのを推奨しています。
ファイルシステムの動作がLinuxカーネルによって違うというお話、とか色々
先日とある ioDrive シリーズのユーザーから、特定のファイルシステムでNANDフラッシュデバイスへの書き込みが行われないという件について相談をいただきました。整理してみると： ファイルシステム上に書き込み可能な状態でファイルをオープンする。 一定ペースで、ファイルへ Buffered I/O で書き込み。 ファイルをクローズする。 このとき、特定条件下のXFSでは、（２）の段階では全然フラッシュが発生せず、（３）の段階でまとまったフラッシュが発生するのだそうです。 ストレージ側からすればI/Oが来ていない段階のお話なのでアプリケーション（ミドルウェア）からシステムコールを通じてカーネル側が原因でI/Oが発生しておらず、まとまったギガバイト級のI/Oが発生すれば、それは高速と言われる ioDrive ですらフラッシュに数秒間かかってしまう、ということでした。よく言われるのは、Linux
Linux Storage Filesystem/MM Summit 2014からの便り
Linux Storage Filesystem/MM Summit 2014からの便り：Linux Kernel Watch（1/2 ページ） お久しぶりです、Linux Kernel Watchが帰ってきました。3月に行われた「Linux Storage Filesystem/MM Summit 2014」の主なトピックを紹介します。 皆さん、お久しぶりです。私は今ボストンで、米レッドハット常駐という立場でRed Hat Enterprise Linux（RHEL）開発に携わっています。 今回はサンフランシスコ近郊のナパバレーで2014年3月24～25日に行われた「Linux Storage Filesystem/MM Summit 2014」（以下LSF/MM）の中から面白かったトピックをピックアップしてお届けしたいと思います。 LSF/MMはLinux Foundation主催で行
LinuxでTCP_DEFER_ACCEPTが有効でもaccept後readできない理由
listen()のbacklogが不足した際のTCP_DEFER_ACCEPTの動作について - blog.nomadscafe.jpという記事の中で、listen backlog があふれた後に accept(2) すると、その後の read(2) が EAGAIN を返したり、接続が不安定になるという事象が説明されていました。気になったので調べてみたことをまとめます。 結論から言うとこれはLinuxの仕様です。manのtcp(7)を見ると、 TCP_DEFER_ACCEPT (since Linux 2.4) Allow a listener to be awakened only when data arrives on the socket. Takes an integer value (seconds), this can bound the maximum number of
第110回カーネル読書会を開催した - 未来のいつか/hyoshiokの日記
かれこれ15年にもわたってこんなことをやっている。震災のあった2011年から先日まで活動をほぼ休止していたが、先日再開した。 Kernel Code Reading Party, #ylug_110 2014/05/02 from Hiro Yoshioka YLUG (横浜Linux Users Group)の年表をみてみると第1回カーネル読書会は1999年4月28日に溝口で開催した。 http://www.ylug.jp/modules/pukiwiki/?history 駅そばの公民館みたいなところでミーティングをして、その後、居酒屋で宴会。 そもそものきっかけはYLUGのメーリングリストでLinuxのシステムコールはどうやって実装しているのかを質問したところだれかが、それはソフトウェア割り込みで実装しているというのを教えてくれて、おお、それはすごい、じゃあ、そのコードを読んでみたい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.linux.org/threads/linux-kernel-reading-guide.5384/