問題タブ [mmu]

背景

私は数週間メインラインを掘り下げており、カーネルが自動的に合体する方法/場合 (およびどのような条件下で) を理解しようとしています。たとえば、512 の 4k PTE を単一の 2M PMD エントリに結合します。 hugetlbfs または THP を使用 - つまり、純粋に x86_64 であるためです。

私は以前、カーネル内の TLB/MMU/ページング サブシステムがこれを検出し、正しいことを実行するという仮定に沿っていましたが、実行時に debugfs の kernel_page_tables に表示される内容からすると、そうではないようです。大きな .text セクション モジュール (> 5MB) を使用したテスト。

質問）

1) カーネルが x86_64 アーキテクチャでページを大きなページに自動的に結合する場合、これを行うにはどのような条件を設定する必要がありますか?

2) カーネルがこれを自動的に行わない場合、手動で 512 個の 4k PTE を取得し、それらを結合/変換して PMD に入れるにはどうすればよいですか?

ヒントが必要です。私はこれをすべて自分で解決したいと思っていましたが、数週間が経ち、無謀な放棄で頭を悩ませています.

どうもありがとう

sc。

このメモリ管理ユニットのコードがあります。2つのImplementsで抽象アルゴリズムIalgoを作りました。MMU クラスでさまざまな状況を処理したいと考えています。これを行うために、RAM を作成する容量を取得し、Ialgo (2 つのアルゴリズムの 1 つ) を取得するメソッドを作成しましたが、「algo」メンバーに対して new を実行し、導入した algo のクラスを取得する方法メインのメソッドについて。コードは次のとおりです。

uboot でメモリ テストを作成する必要がありますが、キャッシュを無効にする必要があります。データ キャッシュと MMU を完全に無効にするように p15 c1 を構成できることはわかっていますが、それは危険すぎるようです。それを行うよりエレガントな方法はありますか？メモリ マッピング中に属性を設定するのが好きですか?

また、uboot のコマンドの場合、キャッシュはおそらく既に無効になっていると言われましたが、それを証明することはできません... 誰か助けてくれますか? ありがとう

L2 ページ テーブルのベース アドレスはどのように決定できますか? (ARM Cortex-A9 を使用)

たとえば、7KB のデータ空間を必要とし、アドレス 0x0 から始まるプログラムがある場合、4KB のページが 2 つ必要です。そのために、L2 ページ テーブルのベース アドレスを指すエントリを L1 ページ テーブルに追加します。次に、そのように L2 ページ テーブルに 2 つのエントリを追加します (最初のページは addr = 0x0、2 番目のページは 0x1000)。

今、私がまだ理解していないことが1つあります。L2 ページ テーブルのベース アドレスを特定するにはどうすればよいですか? L1 ページ テーブルの直後にテーブルを配置する必要がありますか?

アドレスはどこに保存できますか? L1 ページ テーブルのベース アドレスがコプロセッサ レジスタに格納されていることはわかっていますが、L2 ベース アドレスを格納するレジスタが見つかりませんでした。

確認すべきもう 1 つの質問は、コプロセッサ レジスタ TTBR0 と TTBR1 の両方が L1 ページのベース アドレスを保持していることです。それぞれ独自に。L1はTTBR0、L2はTTBR1じゃないですよね？

(できれば) 簡単な質問です。

ARM 密結合メモリに MMU ページ テーブルを作成できますか、それとも作成できない制限がありますか。

このタスクに非常に適していると思われる 16k のデータ TCM があります (命令 TCM にはセキュア ワールド コードが含まれます) が、MMU を有効にするとアボート例外が発生します。

セキュア ワールド コードをコンパイルして SRAM をターゲットにすると、すべてが期待どおりに機能します。問題は、この SoC では、TrustZone をまったく尊重しない FPGA のようなデバイスから SRAM を利用できることです。

ここで何かが足りないのですか、それとも、これをすべて機能させるために自分で小さな RAM を切り開く必要がありますか?

私はARM1176JZ-Sに取り組んでいます。

ARM ベースの SoC の次の仕様があります。

• L1 データ キャッシュ = 32 KB、64 B/ライン、2 ウェイ、LRU
• L2 キャッシュ = 1 MB、64 B/ライン、16 ウェイ
• L1 データ TLB (ロード用): 32 エントリ、完全連想
• L2 データ TLB: 512 エントリ、4 ウェイ
• PDE キャッシュ: 16 エントリ (仮想空間 1 MB あたり 1 エントリ)

そして、PDE キャッシュとは何だろうか? TLBに似たものだと思いますが、よくわかりません。

回答
PDE (ページ ディレクトリ エントリ) は、TLB とは別に実装できる中間テーブル ウォーク キャッシュのようです。

Cortex-A15 MPCore プロセッサは、テーブル ウォークの一部として中間レベルの変換テーブル エントリを格納する専用キャッシュを実装しています。

v7-A および v7-R の ARM アーキテクチャ リファレンス マニュアルのセクション B3 を調べましたが、TTBR0 および TTBR1 レジスタで使用されているアドレスが仮想アドレスまたは物理アドレスのどちらであるかがわかりません。

物理的なことが最も理にかなっていますが、私は決定的に知りたいです.

では、このアドレスは物理的または仮想的であると想定されていますか?

ページ テーブルの場所を ID アドレス (PA == VA) としてマップしておく必要がありますか?

(Linux カーネルソースを見ると) のSwap:メトリック/proc/pid/smapsは、指定された pid によってアクセス可能な合計スワップであるようです。

共有メモリが関係している場合、これは実際のスワップ使用量を過大評価しているようです。たとえば、親 pid とそのフォークされた子のスワップ使用量を合計すると、それらがスワップ内に共通の共有メモリを持っている場合、この部分 (スワップされた共有メモリ) が複数回 (pid ごとに 1 回) カウントされるように見えます。

私の質問は、それを共有しているプロセスの数に基づいて公正なスワップ使用メトリックを把握する方法があるかどうかです (同様にPss:)。