「Linuxカーネル2.6解読室」（以降、旧版）出版後、Linuxには多くの機能が追加され、エンタープライズ領域をはじめとする様々な場所で使われるようになりました。 それに伴いコードが肥大かつ複雑化し、多くのエンジニアにとって解読不能なブラックボックスとなっています。 世界中のトップエンジニア達の傑作であるLinuxカーネルにメスを入れ、ブラックボックスをこじ開けて、時に好奇心の赴くままにカーネルの世界を解読する「新Linuxカーネル解読室」プロジェクト。 本稿では、ネットワーク機能の受信処理におけるEthernetドライバについてカーネルv6.8のコードをベースに解説します。 はじめに 前提条件 1. 概要 2. 割り込みハンドラにおける処理 3. ポーリングハンドラ(NAPI)による受信処理 3.1 前提知識: sk_buff構造体 3.2 概要 4. sk_buff構造体の生成 4.
Jul 10, 2011Download as PPT, PDF179 likes65,452 views
1. はじめに 2. Linux カーネルのおさらい 2.1 実行コンテキスト 2.2 ソフトウェア割り込み 3. NAPI とは 3.1 概要 3.2 関連データ構造 3.3 処理の流れ 4. NAPI の問題点 5. 参考資料 執筆者 : 西村 大助 1. はじめに 本稿では、Linux におけるネットワーク受信処理で利用されている、NAPI(New API)と呼ばれる仕組みについて、実装レベルで解説したいと思います。 2. Linux カーネルのおさらい NAPI について解説する前に、前提として Linux カーネルについていくつかおさらいします。 2.1 実行コンテキスト Linux には実行コンテキストとして、大きく以下の２つのコンテキストがあります1。 プロセスコンテキスト プロセス(本稿では、ユーザプロセスだけでなく、カーネルスレッドも含むものとします)を実行するコンテキス
debugfsはprocfsのように、カーネル内部情報を参照するもので、本質機能の目的はprocfsと同じです。ただ実装の仕方がprocfsのような実装上の制約がなく、通常のファイルイメージでファイルを作成するように、ファイルを作成することができます。そしてファイル単位に、ファイルオペレーションコールバック関数を設定可能となります。 カーネルは/procのようにマウントまで行っていません。マウントはユーザランドの操作となり、従ってシステム依存になります。tools/perf/util/debugfs.cにデフォルトで static const char *debugfs_known_mountpoints[] = { "/sys/kernel/debug/", "/debug/", 0, }; とされていて、通常は/sys/kernel/debugにマウントされています。 サンプルです。
XPS 13でいろいろとデバイス上の問題が多発するので、ここは素直にカーネルのビルドにチャレンジする。昔はカーネルビルドは普通にやっていたけど、今はビルドしなくても特に問題が起こることもないし、平和な日々を送ってこれたが、XPSのせいで一変してしまった…。 というわけで、ビルド。ビルドの前に下準備が必要。この辺を参考にして、以下のものを入れておく。build-depをする前に/etc/apt/source.listは変更が必要。 $ sudo apt install kernel-package $ sudo apt install git ccache fakeroot libncurses5-dev $ sudo apt build-dep linux 準備ができたら、適当なディレクトリにカーネルのソースコードを持ってくる。www.kernel.orgを参照する。今回は5.3.1を入れ
Linux 3.3 の cgroup 関連新機能 - TenForwardの日記 で少し紹介した 3.3 の新機能である Network priority cgroup を簡単に試してみました． net_prio に関連するのは以下のうち， $ ls /sys/fs/cgroup/net_prio/ cgroup.clone_children cgroup.procs net_prio.prioidx release_agent cgroup.event_control net_prio.ifpriomap notify_on_release tasks"net_prio.prioidx" と "net_prio.ifpriomap" で，コントロールに使うのは "net_prio.ifpriomap" です． ファイルの中身は以下のような感じ． $ cat /sys/fs/cgroup/
パフォーマンスチューニングガイド 1. 概要 Expand section "1. 概要" Collapse section "1. 概要" 1.1. 本書を読むにあたって Expand section "1.1. 本書を読むにあたって" Collapse section "1.1. 本書を読むにあたって" 1.1.1. 対象読者 1.2. リリースの概要 Expand section "1.2. リリースの概要" Collapse section "1.2. リリースの概要" 1.2.1. Red Hat Enterprise Linux 6 における新機能 1.2.2. 水平方向のスケーラビリティ 1.2.3. 分散システム 2. Red Hat Enterprise Linux 6 のパフォーマンス機能 Expand section "2. Red Hat Enterprise Li
こんにちは、ティアフォーでパートタイムエンジニアをしている佐々木です。 今回はLinuxに搭載されているスケジューラの一つ、SCHED_DEADLINEについて紹介していきたいと思います。自動運転には多数のクリティカルタスクがあり、自動運転の安心・安全をしっかりと確保するためにはこのスケジューラを上手に設定することでこれらのクリティカルタスクが効率的にまた互いにコンフリクトすることなくリアルタイムに処理されることを担保する必要があります。なお、この記事で紹介するコードはLinuxカーネル5.4.0 (Ubuntu 20.04 LTSのベースカーネル) を元としています。 また、ティアフォーでは「自動運転の民主化」をともに実現していく、学生パートタイムエンジニアを常時募集しています。自動運転を実現するためには、Softwareに関してはOSからMiddlewareそしてApplication
コンテナ目線で考えるUnikernelとmicroVM / MicroVM and Unikernel in the container world
はじめに こんにちは、技術顧問の武内です。 本記事はサイボウズの次期インフラ開発チーム(Necoチーム)が遭遇した、CoreOS Container Linux (以降 CoreOS)においてリアルタイムプロセスを実行できないという問題について、次のようなことを記載したものです。 どういう問題なのか どのように根本原因を突き止めたのか 今後どのように対処するのか 問題要旨 本来なら成功するはずのroot権限におけるリアルタイムプロセスの実行が失敗する 根本原因 CoreOSではカーネルのリアルタイムグループスケジューリングという機能が有効になっている 同機能が有効な場合、cpu cgroup配下のプロセスはデフォルトではリアルタイムプロセスを実行できない systemd環境下で生成されたプロセスは何らかのcpu cgroupに所属させられる 対処方法 リアルタイムプロセスが属するcpu c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
