Linux Pipes are Slow | Quentin Santos
vmsplice is too fast Some programs use a particular system call “vmsplice” to move data faster through a pipe. Francesco already did a deep dive on using vmsplice to make things fast. However, while experimenting with it, I noticed that, when not using vmsplice, Linux pipes are slower than what I would have expected. Since you cannot always use it, I wanted to understand exactly why that was, and
WSL2標準kernelでmodprobe - Qiita
<m>だとカーネルモジュールが生成され、ドライバが含まれないkernelが生成されてしまいます。 WSLではlinuxカーネルに必要なドライバを全部取り込む流儀があるようで、面倒事を避けるためにカーネルモジュール指定は止めておきましょう。 C:\Users\user>ver Microsoft Windows [Version 10.0.22631.3085] C:\Users\user>wsl.exe --version WSL バージョン: 2.1.1.0 カーネル バージョン: 5.15.146.1-2 WSLg バージョン: 1.0.60 MSRDC バージョン: 1.2.5105 Direct3D バージョン: 1.611.1-81528511 DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windo
ハードウェアのタイムスタンプを使用してネットワークの待ち時間を測定する方法 | IIJ Engineers Blog
I'm a researcher at IIJ Research Laboratory working on the performance, security and reliability of distributed systems. 今回は、IIJの技術研究所にインターンシップとしてドイツから来日していたフォーゲル アーネさんの研究を紹介します。彼は博士号候補者で一緒に働いていました。研究内容は、ネットワークカードのハードウェアタイムスタンプについてです。それではご覧ください。 （以下フォーゲルさんの記事） この投稿では、ハードウェアのタイムスタンプを使用して、単純なpingコマンドよりもきめ細かくネットワークの待ち時間を測定する方法を探ります。 動機 2つのノード間のネットワークレイテンシを調べたい場合どうすればよいでしょうか？ シンプルな方法はpingを使うことでしょう： $
LTS版「Linux」カーネルのサポートが短縮へ--背景にメンテナーの苦悩
現地時間9月19日からスペインのビルバオで開催されていた「Open Source Summit Europe」で、Linuxカーネル開発者であり、LWN.netの編集責任者を務めているJonathan Corbet氏が、Linuxカーネル関連の新しい点や今後の動きについて発表した。 ここではその中から、今後の大きな変更点の1つを紹介したい。それは、Linuxカーネルの長期サポート（LTS）が6年から2年に短縮されるということだ。 LinuxカーネルのLTS版には現在のところ、6.1と5.15、5.10、5.4、4.19、4.14の6つがある。これまでであれば、4.14は2024年1月にサポートが終了し、別のカーネルが追加されていた。しかし今後は、4.14とその次の2つのバージョンのサポートが終了しても、別のカーネルがそれに取って代わることはない。 なぜだろうか。Corbet氏は単純なことだ
[Ubuntu] RustでLinux kernel モジュールを開発する | DevelopersIO
Introduction Linux kernelの6.2からRustでカーネル開発をするための基本的なサポートが導入されましたが、 メジャーなディストリビューションは6.2をデフォルトで搭載していませんでした。 なのでRustカーネルを試そうとした場合、 カーネルのソース持ってきてカーネルビルド関連のソフトウェアやライブラリをインストールし、 Rust関連のオプションつけてビルドしなおして Rustで書いたカーネルモジュールをビルドして QEMUとかUTMとかでようやく動作確認ができます。 とりあえずHelloWorldするだけでも、かなり面倒です。 しかし先日、Ubuntu 23.04 Lunar Lobsterがリリースされました。 これは標準でLinux Kernel 6.2を搭載しているので、面倒な手順を踏まなくても Rust製のLinux kernelが動きます。 また、素晴
![[Ubuntu] RustでLinux kernel モジュールを開発する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/dd5670c7677ae91c06d8d1435b350baf9e3cff8a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F09%2Frust-logo-1200x600-1.png){kind=logo}
トラブルシューティングから Linux カーネルに潜り込む
Bidirectional Quadratic Voting Leveraging Issue-Based Matching
「バニラ」の起源について
IBMのBookMasterでは、デフォルトを"vanilla"、特別な設定を"mocha"と呼んでいたらしい。 http://web.archive.org/web/20211224091337/ftp://public.dhe.ibm.com/printers/products/dcf/samples/B2H.HTM 「Chapter 6. Caveats and restrictions (what's supported and what's not!)」に以下の記述がある。 Conditional sections (.cs) and BookMaster's "vanilla" DVCF macros (.CONFIG and .WHEN) are supported, but not BookMaster's "mocha" DVCF macros (e.g. .USING,
Linuxで動くNICドライバの開発をしている - BYB
概要 おことわり 流れ [前半]:NICドライバ実装に必要な作業 insmod/rmmod 時のエントリポイントとなる関数を用意 pci_diriver構造体を定義して、ドライバを登録 net_deviceとして登録 net_deviceハンドラ関数を用意してハンドラテーブルに登録 割り込みの定義(未動作確認) MMIOレジスタを適切に初期化して、実際にパケットを処理する部分を書いていく(未実装) ハンドラとスケジューリング [後半]:Linuxカーネル関連で詰まったところ insmod時のカーネルクラッシュ インターフェースのstateがUPにならない問題 ソースコード さいごに 概要 Linuxで動くe1000eドライバを開発しようとしており、ドライバと紐付けたNICのstateがupになるところまで進めました。 個人的に忙しくなった都合で一旦ここでプロジェクトを止めるため、備忘録とし
令和にふりかえる C10K 問題
C10K 問題 (the C10K problem) は1999年に Dan Kegel が発表した文章、ならびにそこで提示された「問題」です。文章はその後も2000年代前半に何度か更新されているのですが、さすがに令和に読み返すと、当初の問題意識がわかりにくいところがあります。 2000年からの10年は、 ソフトウェア面では、select(2), poll(2) にかわる新しいシステムコールの実装と、それを使ったアプリケーションの普及 ハードウェア面では、x86 アーキテクチャの64ビット移行、仮想化命令の追加と、マルチコア化 さらにそこにクラウドも登場する、面白い時代でした。ここでは、それらの出来事を中心に、さらに、当時の雰囲気をつたえるような日本国内のブログやインタビュー記事をまとめることで、C10K 問題が、さまざまな側面から解決されていく流れを説明したいと思います。 書き足したいと
Linux でのハングタスクについて - 赤帽エンジニアブログ
Red Hat でコンサルタントをしている菅原と申します。 この記事では、意外とあまり説明されていないような気がする Linux システムで発生するハングタスクについて少し説明したいと思います。現場のシステムでもハングタスク検知の設定がされていることが多いと思いますが、ハングタスクとは何なのかを正しくご理解いただくことで、ハングタスク検知を行う目的が明確になること、また、実際の障害事例もご紹介することで、通常あまりハングタスクと関連づけて考えないような設定でもハングタスク発生につながる場合があることを知っていただき、少しでもシステム管理や障害の理解、障害対応などのお役に立てれば幸いです。 なお、この記事では RHEL のみを対象に書いていますが、他の Linux ディストリビューションにも適用される内容と思います。 ハングタスク (hung tasks) とは ハングタスクとは読んで字のご
Linuxにおけるデバイスファイルの仕組み
Linuxにおけるデバイスファイルはデバイスをファイルという概念を通して扱えるようにしたものです。デバイスファイルは通常のファイルと同様に読み書きを行うことができます。しかし実際には、その読み書きはデバイスドライバを通じてデバイスの制御に変換されます。 この記事では、デバイスファイルへの読み書きがどのようにデバイスの制御に変換されるのかを説明します。デバイスファイルはデバイスドライバとファイルの2つのコンポーネントに依存したものであるので、最初にデバイスドライバ、次にファイルについて説明し、最後にデバイスファイルがどのようにデバイスドライバと結び付けられるかを解説します。 この記事の内容は主に詳解 Linuxカーネル 第3版及びhttps://github.com/torvalds/linux/tree/v6.1によります。 目次 デバイスドライバ デバイスドライバの実例 read_wri
Linux_Kernel_Newbies - Linux Kernel Newbies
Kernelnewbies is a community of aspiring Linux kernel developers who work to improve their Kernels and more experienced developers willing to share their knowledge. Kernelnewbies can be found on the MailingList, IRC (irc.oftc.net #kernelnewbies), and this wiki. Outreachy Potential Outreachy applicants, please go to the Outreachyfirstpatch. ChangeLog A human readable changelog for the Linux kernel
procfs の hidepid オプションについて調べた
profs の hidepid オプションの値 procfs のマウントオプションに hidepid というオプションがあることを知った。 man で確認すると 0~3 の値を取るらしい。 hidepid=n (since Linux 3.3) This option controls who can access the information in /proc/[pid] directories. The argument, n, is one of the following values: 0 Everybody may access all /proc/[pid] directories. This is the traditional behavior, and the default if this mount option is not specified. 1 Users
ペパボ トラブルシュート伝 - node プロセスの general protection fault を追う - abort(3) の意外な実装 - Pepabo Tech Portal
セキュリティ対策室の伊藤洋也 @hiboma です。 業務中に、Haconiwa コンテナ で動くとある node プロセスが general protection fault ( 一般保護違反! ) を起こしてdmesg にログを残す現象を調べ、問題解決にあたっていました。その際の痕跡をまとめなおして記したエントリになります。 エントリの概要 本エントリでは、以下のような内容を扱います。 Haconiwa コンテナの node プロセスが general protection fault を起こしている ライブラリ関数 abort(3) の概要 abort(3) がプロセスを停止する方法の検証 node プロセスが abort(3) を呼び出すケース glibc x86系の abort(3) 実装が HLT 命令を呼び出し、general protection fault を起こすこと
Linux Kernel: カーネルモードで CPU 掴んでるタスクのバックトレースをとりたい - hibomaの日記
表題の通りなのだが、結論からいうと sysrq-trigger を使うのがいいみたい 「特定のタスクがクリティカルセクションを実行していてボトルネックとなっているが、どのタスクなのか分からない」という事象を正確に観測したくて、このテーマで調べました カーネルモードで CPU 掴んでるタスクを作る まず実験用にカーネルモジュールをこしらえた github.com debugfs 上のファイルを read(2) したタスクが spinlock を掴んだまま無限ループに突入する、という単にバグってるカーネルモジュールになる. これでカーネルモードで刺さっているタスクを擬似的に再現する 実験 上記のカーネルモジュールをインストールすると /sys/kernel/debug/foreverspin が生えるので、これを cat する vagrant@bionic:/ $ sudo cat /sys/
Linux Kernel: rtnl_mutex を長時間 ロックして刺さった状態を観察する - hibomaの日記
Linux Kernel で struct net_device や Routing Netlink の処理を排他制御する mutex である rtnl_mutex を任意の時間 ロックするカーネルモジュールを作成して、rtnl_mutex のロックがユーザランドのプロセスやカーネルスレッド等にどういった影響を及ぼすかを観察する ... というエントリです Linux カーネルの話や、strace, gdb, /proc/$pid/stack を使ったデバッグ方法に興味あるかた向けです 経緯 とあるサーバで動いてる大量のプロセスが rtnl_mutex をロックする箇所やそれに関連していそうな箇所で TASK_UNINTERRUPTIBLE でブロックしてしまい、障害を起こしているのに遭遇して原因を追いかけていたのでした 障害の再現が難しくて困っていたのだが、別のアプローチとして 「rtn
Linuxカーネル5.0ではCFQ, Deadlineと言ったシングルキュースケジューラが全て削除されてカーネルのデフォルトIOスケジューラ設定も無くなっていました
Linuxカーネル5.0ではCFQ, Deadlineと言ったシングルキュースケジューラが全て削除されてカーネルのデフォルトIOスケジューラ設定も無くなっていました Linux 5.0での変更 5.0での全体の変更はここで見れます. 今回ビックリしたのは block/cfq-iosched.c と block/deadline-iosched.c の削除です. CFQが主にSSDで性能が良くないことは知っていましたが, Deadlineが削除されるとは思っていませんでした. まあパフォーマンスの最大化 - ArchWiki を信じるならCFQとDeadlineはマルチスレッドに対応していないので削除は時代の流れでしょう. 言及はコミット上ではここでされています. すごい破壊的変更なのに, Linux 5.0のリリースニュースにもチェンジログをまとめたサイトでも全然取り上げられて無くて, m
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebAssembly Night_Wasmを実行するunikernelとWasmコンパイラ
【Ubuntu日和】 【第13回】Ubuntuの商用サポートと、無償で使える「Kernel Livepatch」機能
A Heavily Commented Linux Kernel Source Code