systemd & systemctl - とみぞーノート
現在のtargetを変更するにはsystemctl isolateを使う。例えば、以下のようにするとRescueモード(シングルユーザモード)に遷移する。 # systemctl isolate rescue.target 現在のtargetを取得するには、systemctl list-units --type targetを使う。 # systemctl list-units --type target <略> graphical.target loaded active active Graphical Interface <略> multi-user.target loaded active active Multi-User System <略> ただし、targetには依存関係があり、このコマンドだと読み込んでいるtargetを全て表示してしまうので、結局どのtargetで動作し
sysfsとkobject - Linuxの備忘録とか・・・(目次へ）
sysfsは仮想的なファイルシステムとして、カーネル空間のリソースをユーザ空間に公開するもの、procfsで実現できないからsysfsというわけでなく、実際のところsysfsとprocfsの機能的な違いはない。実装の違いで言うなら、procfsのコールバックの処理内容とそのprocファイルの関連性はないのだが、sysfsではそのsysファイルとコールバックの処理に関連性を持たせているということか。 本サンプルはカーネルのソースとして組み込まれているものを、kobject(kernel object)の構造を理解しやすくするために一部変更したものである。 #include <linux/kobject.h> #include <linux/string.h> #include <linux/sysfs.h> #include <linux/module.h> #include <linux/
vsyscall - Linuxの備忘録とか・・・(目次へ）
86ではシステムコールとしてint80とペンティアムで実装されているsysenterとがあるのですが、glibcでは直接int80ないしsysenterとしてコード展開していません。glibcは__kernel_vsyscallとしてリンクしています。 カーネルは立ち上がり時、ラベルを__kernel_vsyscallとして、int80ないしsysenterで、システムコールするモジュールをカーネルのページに読み込み、ユーザプロセスを起動する時に、このページのモジュールをプロセスにリンクすることで、int80ないしsysenterに透過的な動作を実現しています。 start_kernel()関数からcheck_bugs()関数が呼ばれ、そこからidentify_boot_cpu()そして、sysenter_setup()とコールされます。ここでシステムコールのモジュールがページに読み込まれ
PageCache - Linuxカーネルメモ
1. 概要 LinuxのディスクキャッシュはPageCacheとして実装されている。PageCacheはストレージ上のファイルをキャッシュする(*1)。PageCacheはファイルの先頭から物理ページサイズ単位に区切ってページ単位にキャッシュする。このため、"Page"Cacheと呼ばれる。 ファイルのRead/WriteはPageCacheを経由する。 (*1) 同じようなディスクキャッシュとしてBufferがある。Bufferはファイルではなくディスクブロックをキャッシュする。こちらはi-nodeなどのディスク上のメタデータなどをブロックリードする時などに使用される。 2. PageCacheの管理方法 2.1 address_space構造体 PageCacheはstruct address_space (*1)を元に管理される。 図1にページキャッシュがstruct address
メモリーマップ - Linuxの備忘録とか・・・(目次へ）
通常のファイル読み書きは、openでファイル構造体を取得し,read/writeでユーザのメモリー空間とのやりとりを行う。ファイルとのデータは、IOブロック層に渡って、実際の物理デバイスへとなるのだが、IOブロック層は、ユーザで渡されたデータ(open/writeの引数)と直接やりとりを行うものでない。IOブロック層はページキャッシュと、そして、ユーザへはこのページキャッシュを通してやり取りする。実際read/write処理では，まずinode->page_treeのradix-treeでリストされるページキャッシュに、目的とするデータが存在するか確認する。なければページを割り当て、このinode->page_treeのradix-treeに追加して、このページへ物理デバイス上のデータを読み込んだのち、（ページキャッシュがあるなら物理デバイスから読み込む必要はない。）ページキャッシュとユー
FrontPage - Linuxカーネルメモ
Linux Kernel(2.6)の実装に関するメモ書き 書き殴っているので書き方/内容にムラあり。 3.6系に関する記述は【3.6】と記載。 カーネル プロセス プロセスのBlockとWakeup プロセスの優先度 コンテキストスイッチ プリエンプション スケジューラ RunQueue WaitQueue WorkQueue 例外処理 割り込み処理 ページフォルト ページフォルト - 個々のハンドラ ソフト割り込み システムコール 排他制御関連 モジュール 64bit環境での32bitプロセスの動作 メモリ管理 アドレス空間 アドレス空間の管理 カーネル空間のメモリマップ 64bitでのアドレス空間 HighMemory kmalloc,vmalloc 物理ページ管理 スラブアロケータ Rmap proc/meminfo 空きページの確保 kswapd Swap Swap - Swap領
FrontPage - Xnuメモ
Mac OS XのカーネルXnu(Xnu is Not Unix)のメモ。 xnu-792.6.70を基本的にi386版で。 Introduction カーネルソースのディレクトリ構造 カーネル スケジューラ スレッドのCPU利用率の計算 プロセス スレッド コンテキストスイッチ WaitQueue スレッドのブロックと起動 スレッドの生成と終了 プリエンプション 排他制御関連 例外処理 ページフォルト Asynchronous System Traps メモリ管理 vmmap VM Object pmap メモリの割り当て 物理ページ管理 ページング アドレス空間の複製 Pager Default Pager Universal Page List ページアウト ネットワーク プロトコル処理はbsd/net,netinet,netinet6でFreeBSD側に実装されている。 受信処理
スラブアロケータ - Linuxカーネルメモ
linux-2.6.16.1でのメモ。 1. 概要 Buddy Systemでは物理ページ単位のメモリの確保になるため、あるメモリオブジェクト(例えばプロセスのtask_structとか)を動的に確保するのには向いていない。スラブアロケータではBuddy Systemとの間に入り、メモリオブジェクトの確保／解放機能を提供する。 スラブアロケータでは、あらかじめメモリオブジェクトに対してキャッシュ(kmem_cache)を作っておき、そのキャッシュからメモリオブジェクトを取得する形をとる。キャッシュは足りなくなれば自動的に確保されるようになっている。 Slabから取得するバッファはBuddy Systemから取得しており、以下の特徴がある。 仮想アドレスに対して物理ページが割り当て済み(アクセスしてPageFaultになることはない)物理的に連続ページ 2. スラブアロケータの特長スラブアロ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
