［速報］WindowsにLinuxカーネルをバンドルへ、Windows Subsystem for Linux に最適化。Microsoft Build 2019 － Publickey
近い将来、WindowsにLinuxカーネルがバンドルされる方向であることが、マイクロソフトの「Windows Command Line Tools For Developers」ブログに投稿された記事「Shipping a Linux Kernel with Windows」で明らかになりました。 Windows 10には、Linux互換機能を実現する「Windows Subsystem for Linux」（WSL）が搭載されています。これまで、WSLを機能させるにはユーザーがWSL上にLinuxを導入する必要がありました。 今後のWSLではこれを改め、WSLに最適化されたLinuxカーネルが最初からWindowsに含まれるようになり、ユーザーはカーネルを除くユーザー空間に対応する部分のLinuxを導入する方式になるとのことです。 「Shipping a Linux Kernel wi
Linux 5.0がリリース - 待望のFreeSyncをサポート | ソフトアンテナ
Linux開発者のLinus Torvalds氏は3月3日(現地時間)、Linux mainline Kernelの最新版「Linux 5.0」をリリースしたことを発表しました(Phoronix)。現在最新版のソースコードを公式サイトからダウンロードすることができます Linux 5.0は当初Linux 4.21として開発が始まりましたが、開発期間の途中で名称が変更され、そのまま正式リリースに至っています。 Linux 5.0の新機能としては、AMD RadeonのFreeSyncのサポートや、Intel Icelakeその他最新CPUのための機能の追加、Logitechの高解像度スクロールへの対応、Raspberry Pi タッチスクリーンのサポート、HiDPI/Retinaディスプレイ用の新しいコンソールフォントの追加などがあげられています。新機能の詳細はPhoronixの記事「The
Linuxカーネルをgdbでデバッグ（またはディストリビューションのカーネルを使うときは当たってるパッチにも注意しよう） - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
この記事はLinux Advent Calendar 2018の1日目ですΣ(ﾟ∀ﾟﾉ)ﾉｷｬｰ イントロ ほんとは別の内容にしようと思ってたのですが、進めてる途中でカーネルのデバッグをするハメになったのでカーネルデバッグをネタにしてみました。カーネルのデバッグと言っても普通のデバッグと変わらないよね〜というところがわかると思います。（｀・ω・´)<ｺﾜｸﾅｲﾖｰ デバッグの環境としてはlibvirt(qemu)で動いてるゲスト環境にホスト側からgdbでデバッグする感じです。ディストリビューションはFedora 29です。デバッグするカーネルはFedoraのカーネルで4.19.2-300.fc29.x86_64です。 テストコード テストコードは↓です。これはdebugfsのディレクトリ（大概は/sys/kernel/debug/だと思います）にopen-testってファイルを作って、その
Linuxのテスト用に、ハングアップやパニック状態にするカーネルモジュールを作ってみた - のぴぴのメモ
テストのために、AWSのAmazon Linuxのインスタンスをカーネルレベルでハングアップさせたかったので、テスト用のカーネルモジュールを作ってみました。 できること カーネルのハングアップ(ping応答もできないレベル。プリエンプションをdisableにして実現) 中途半端なハングアップ(ping応答は帰るレベル。リエンプションはenable) カーネルパニック(echo c > /proc/sysrq-triggerと同じ) 使い方 カーネルモジュールのビルド コードはGitHubにあります。 github.com (1) 必要なパッケージのインストール カーネルモジュールのビルドに、gccとkernel-develが必要になります。(Amazon Linuxの場合) sudo yum -y install git gcc kernel-devel(2) ソースコードをローカルに持っ
Linuxカーネルのソースコードを機能とレイヤーで分類して表示してくれる「Linux kernel map」
Linuxのカーネルは膨大な数のソースコードから成り立っており、どこに何の処理が書いてあるのかぱっと見当をつけるのにはかなりコードを読み込む必要があります。「Interactive map of Linux kernel」はそのソースコードを機能とレイヤーで分類して表示してくれるサイトということで、使い勝手を試してみました。 Interactive map of Linux kernel http://www.makelinux.net/kernel_map/ サイトにアクセスし、ロードが終わると下の画像のように6列6行の表が表示されます。列が機能の分類を表しており、「インターフェース」「システム」「処理」「メモリー」「ストレージ」「ネットワーク」という分類になっています。行はレイヤーを表しており、上からシステムコールなどの「ユーザースペースインターフェース」、「バーチャル」、「ブリッジ」
Linux シグナルの基礎
TLPI (The Linux Programming Interface) 再々。 TLPI の輪読の際に @matsumotory よりシグナルセットあたりをまとめるようにと指令が出たので、拙遅な感じでまとめました。 シグナルとは プロセス間通信の一種。「プロセスにシグナルを送信すると、そのプロセスの正常処理に割り込んで、シグナル固有の処理(シグナルハンドラ) が実行される」プロセス側では、シグナルを受信した際の動作(シグナルハンドラ) を設定することや、シグナルをブロックすることも可能。 コンソールで、プロセスを終了させるためにkill -9 <PID>とかCtrl+Cとかした際にも、対象プロセスにシグナルが送信されている。 ちなみに、PID「1」の init や systemd にkill -9 1しても何も起らない。(そういえば昔、oom-killer に init を殺された覚
Linuxのしくみを学ぶ - プロセス管理とスケジューリング
プロセスとマルチタスクの実現 Linuxは、多数のプロセスを同時に動作させる事が出来るマルチタスク環境を実現しています。 psコマンドやtopコマンドを実行しプロセスのリストを取得すると多数のプロセスが実行中である事がわかります。 また、これらのプロセス全てが同時に平行して動作しているように見えます。 これはどのようにして実現されているのでしょうか。 一般的に、１つのプロセッサは同時に複数のプログラムを実行する事が出来ません1。 そこで、マルチタスクをサポートするOSでは複数のプロセスを非常に短い時間ずつ切り替えながら実行する事で、体感上は複数のプロセスが同時に実行されているように見せています(図1)。 このような仕組みを実現する為にどんな機能がカーネルへ実装されているのか順に見ていきましょう。 プロセスの切り替え CPU上で処理中のデータを失う事なく現在のプロセスから別のプロセスに切り替
Linuxシステムコール徹底ガイド | POSTD
要約 この記事では、LinuxカーネルにてLinuxプログラムがどのように関数を呼び出すのかについて紹介していきます。 システムコールを行う様々な方法、システムコールを行うための独自のアセンブリの作成方法（例あり）、システムコールへのカーネルエントリポイント、システムコールからのカーネルイグジットポイント、glibcのラッパ関数、バグなど多くの点について説明します。 要約 システムコールとは？ 必要条件に関する情報 ハードウェアとソフトウェア ユーザプログラム、カーネル、CPUの特権レベル 割り込み モデル固有レジスタ（MSR） アセンブリコードでシステムコールを呼び出すことの問題点 レガシーシステムコール 独自のアセンブリを用いたレガシーシステムコールの使用 カーネル側での int $0x80 エントリポイント iret を使用したレガシーシステムコールからの復帰 高速システムコール 3
CPU使用率100％のWebサーバをOSのチューニングだけでCPU使用率20%まで改善する - 人間とウェブの未来
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
systemd時代に困らないためのlimits設定 | 外道父の匠
数年前に、こういう記事「ulimitが効かない不安を無くす設定」を書きました。しかし、ディストリビューションのバージョンが上がり、デーモン管理が systemd に変わったことで、インターネットのゴミとなりつつあります。 そのため今回は、その次世代バージョン的な内容ということで、systemd の場合はこうしておけば見えない敵と闘うこともなくなるはずです、というものになります。例によって、抑えきれていないパターンがあったら御免なさいです、押忍。 limits設定で目指す所 復習になりますが、limits の設定で困るのはだいたいこういうパターンでしょう。 作業中ユーザーのシェルのlimits設定が思い通りにならない コンソール／SSHログインしてデーモンを再起動したら、limits設定が戻っていた su/sudoを使ってデーモンを再起動したら同上 デーモンをシステムに自動再起動させたら同上
開発環境構築 | Linuxデバイスドライバ開発入門
デバイスドライバをビルドするためには、カーネルバージョンと同一バージョンの、kernel-develとkernel-headersパッケージが必要です。 そのため、まずは自身の環境のカーネルバージョンと上記2つのパッケージがインストールされているかどうかを調べます。 # uname -r 2.6.18-238.el5 # rpm -aq | grep kernel kernel-headers-2.6.18-238.el5 kernel-devel-2.6.18-238.el5 上記例では、カーネルのバージョンが「2.6.18-238.el5」であり、同バージョンのkernel-develとkernel-headersパッケージがインストールされています。 もし、インストールされていないのであれば、yumなどを使いインストールします。 # yum install kernel-devel
Linuxカーネルハッカーになる4つの方法 | Yakst
Linuxカーネル開発者になりたいと思っても、まず何から手をつけたらいいか分からず、始める前から挫折する人も多いだろう。すぐ始められる最初の一歩の例が、筆者の経験を交えて4つ挙げてある。 (これは、CUSECというイベントでの、カーネルは怖くないという話の続き) カーネルプログラミングを始めるにはどうしたらいいか、アドバイスを求めたことがある。その時は、こう回答があった。 仕事のためにカーネルを理解する必要がなくても、やってみたらどうだろう？ Linuxカーネルメーリングリストに登録してみて、精一杯理解しようと頑張ってみよう。 メインのLinuxカーネルの一部にならないコードを書いているなら、時間の無駄だ。 これは私にとっては、全然、少しも役に立たなかった。そんなわけで、ここでは、あなたなりにOSやLinuxカーネルがどう働くか、楽しみながら理解していくための、いくつかの戦略について書いて
Linuxのハードウェアに関する詳細情報を取得する『Inxi』コマンド | 俺的備忘録 〜なんかいろいろ〜
今回は、Linuxが搭載されているハードウェアのパーツごと、例えばサウンドボードやマザーボード、ハードディスク等のベンダーや型番といった詳細情報を取得出来るコマンド『Inxi』を紹介する。 1.インストール まずはインストールから。 以下のコマンドを実行しインストールを行う。 Debian/Ubuntu sudo apt-get install inxi RHEL系 sudo yum install inxi --enablerepo=epel 2.コマンドの実行 さて、それでは実際にコマンドを実行してみよう。まずはオプションを付けず、デフォルトの内容を表示してみる。 以下の内容は、実際に自宅で用いてるマシンのデータを表示している。 $ inxi CPU~Quad core Intel Core2 Quad Q9550 (-MCP-) clocked at 2833 Mhz Kernel~
EXT4 vs XFS vs Btrfs vs ZFSをfioでベンチマークを取ってみました。 - Qiita
概要 CentOS7のデフォルトのファイルシステムがXFSとなりました。 mkfsコマンドでも、minix, xfs, btrfsが使えるようになりました。 そこで気になるファイルシステムを色々調べ、ベンチマークを自分なり取ってみました。 多少なりともご参考になればと思います。 色々なファイルシステム こちらをご参考ください。 http://qiita.com/sion_cojp/items/c8e015db39ddbf43012e それぞれファイルシステムを作ってみる 今回の環境は CentOS6（ホスト） 4Core, MEM:32G, HDD:300G CentOS7（ゲスト。こちらで計測しております。） vCPU *1, MEM:4G, HDD:40G 容量が少なかったため、btrfsのベンチマークが終わった後、zfsにファイルシステムを変更し検証をしております。 ### zfsの
Linuxのブロックデバイスレベルで実現するrsyncより高速な差分バックアップについて - ゆううきブログ
社内で論文輪読会みたいなことやってて、そこで紹介した論文の内容についてです。 最近、Graphite に保存しているデータのバックアップ（データ同期）に rsync 使ってて、かなり遅いので困ってた。 LISA っていう 大規模システム、sysadmin 系のカンファレンスがあって、ここから論文探してたら、ちょうど巨大データの高速バックアップの実装の話があったので読んでみた。 論文概要 dsync: Efficient Block-wise Synchronization of Multi-Gigabyte Binary Data - https://www.usenix.org/conference/lisa13/technical-sessions/presentation/knauth - Thomas Knauth and Christof Fetzer, Technische U
Linuxカーネルチューニングのメモ - 電子書籍と趣味の部屋
Post navigation ← Previous Home > Web関連 > 開発 > Linux > Linuxカーネルチューニングのメモ Linuxカーネルチューニングのメモ サーバー向けにLinuxカーネルのチューニングを行った際のメモです。 設定内容 今回行った /etc/sysctl.conf の設定内容は書きの通りです。 各パラメータの説明はコメントとして残しておきます。 # 共有メモリの最大サイズ。サーバーの搭載メモリ(1GB)に合わせて変更 kernel.shmmax = 1073741824 # システム全体の共有メモリ・ページの最大数 kernel.shmall = 262144 # システム全体のプロセス数の上限 kernel.threads-max = 1060863 # システム全体のファイルディスクリプタの上限 fs.file-max = 5242880
RHEL6/SL6/CentOS6 ネットワーク設定まとめ
5まではifcfg-ethX内のHWADDRやmodprobe.confなんか使ってethXの順番をいじってたが、6以降は全てudev一本で制御できるようになっている(5でもudevを使ってif順序を制御することは可能。 udevでのネットワーク設定は以下にまとめられている。 /etc/udev/rules.d/70-persistent-net.rules # PCI device 0x8086:0x100e (e1000) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:c8:16:8d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" 下線部部分でMACアドレスとデバイス名の関連付けを行っている。 NAME=の部分は好きに設定できるのでこんな事
CentOS 6.2 で RPS/RFS を使ってネットワークの割り込み処理を複数コアに分散してみた - blog.nomadscafe.jp
以前(2010年)に「アプリケーションがマルチスレッドでもマルチコアCPUを活かせない件」というエントリにてCPUのコアが増えても割り込み処理が分散されないのでスケールされないと書いたけど、その後Linux KernelにRPS/RFSなる機能が追加され、割り込み処理が分散できるようになり、CentOS 6.2 でも使えるらしいので試してみました。 RPS/RFSについての紹介は VIOPS06で「RPS・RFS等最新Linux Kernel事例」と題してお話してきました http://d.hatena.ne.jp/syuu1228/20110722/1311322653 Linux内核 RPS/RFS功能详细测试分析 http://www.igigo.net/archives/204 が詳しい。2番目のはほぼ読めないけど、性能比較のグラフが分かりやすい。 今回試したサーバは、 OS: C
sched_clock() overflow after 208.5 days in Linux Kernel
えーっと、久しぶりに Linux Kernel にダメダメなバグが発見されて、よりにもよってうちの製品も影響を受けたので、ここに詳細を書くことにした。 つーか。新しい Kernel を使うなら皆で使おうよ。なんだよその「1つだけ」影響を受けて残りは「影響も受けないぐらい古い」ってのは… 概要 大雑把に 208.5日連続運転した Linux Kernel が突如として reboot する。 実機でなおかつ Time Stamp Counter を内包している必要があるので、Pentium4以降のプロセッサ(が、それはようするに今ある Intel 系CPU全部)か、その互換CPUである必要がある。32bit モード、64bit モードの区別はない。 逆に VMware や Xen など、仮想マシン上で動いている kernel に影響はない。これはそもそもバグを内包したルーチンを、仮想マシンで動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://lowlife.jp/yasusii/stories/20.html/