arm

ARM関係

filename remark
00-INDEXthis file
Bootingrequirements for booting
InterruptsARM Interrupt subsystem documentation
msmMSM specific documentation
NetwinderNetwinder specific documentation
PortingSymbol definitions for porting Linux to a new ARM machine.
SetupKernel initialization parameters on ARM Linux
READMEGeneral ARM documentation
SA1100/SA1100 documentation
Samsung-S3C24XXS3C24XX ARM Linux Overview
Sharp-LHLinux on Sharp LH79524 and LH7A40X System On a Chip (SOC)
SPEArST SPEAr platform Linux Overview
VFP/Release notes for Linux Kernel Vector Floating Point support code
empeg/Ltd's Empeg MP3 Car Audio Player
mem_alignmentalignment abort handler documentation
memory.txtdescription of the virtual memory layout
nwfpe/NWFPE floating point emulator documentation
swp_emulationSWP/SWPB emulation handler/logging description

memory.txt

Kernel Memory Layout on ARM Linux

Russell King <rmk@arm.linux.org.uk>
November 17, 2005 (2.6.15)
This document describes the virtual memory layout which the Linux kernel uses for ARM processors.
It indicates which regions are free for platforms to use, and which are used by generic code.
このドキュメントでは、LinuxカーネルがARMプロセッサ用に使用する仮想メモリのレイアウトを記述します。
これは、プラットフォームが使用するためのフリーな領域がどこにあるか、そして、汎用コードによって使用されるのはどこか、を示します。
The ARM CPU is capable of addressing a maximum of 4GB virtual memory space,
and this must be shared between user space processes, the kernel, and hardware devices.
ARM CPUは、最大4GBの仮想メモリ空間アドレッシングを許容します。
この空間は、ユーザ空間プロセス、カーネル、ハードウェアデバイスの間で共有する必要があります。
As the ARM architecture matures, it becomes necessary to reserve certain regions of VM space for use for new facilities;
therefore this document may reserve more VM space over time.
ARMアーキテクチャは静寂するにつれて、新しい設備(機能)を使うために、仮想空間の特定の領域を予約する必要が出てきます。
したがって、このドキュメントは、時間の経過と共に、より多くの仮想空間を仮想空間を予約するでしょう。
Start End Use
ffff8000ffffffffcopy_user_page / clear_user_page で使う。
SA11xx と Xscale では、minicache mappingの設定に使う。
ffff4000ffffffffARMv6アーキ以降の cache aliasing
ffff1000ffff7fffReserved. Platformsはこの領域を使ってはいけない
ffff0000ffff0fffCPU vector page. CPUがヴェクタリロケーションをサポートしていれば、ここにマップされる(Control RegisterのV bitで設定)
fffe0000fffeffffXScale cache flush area. This is used in proc-xscale.S to flush the whole data cache. (XScale does not have TCM.)
fffe8000fffeffffDTCM mapping area. for platforms with DTCM mounted inside the CPU.
fffe0000fffe7fffITCM mapping area for platforms with ITCM mounted inside the CPU.
fff00000fffdffffFixmap mapping region. fix_to_virt()で与えられるアドレスは、ここに配置される。
ffc00000ffefffffDMA memory mapping region. the dma_alloc_xxx()で返ってくるメモリが、ここに動的にマップされる。
ff000000ffbfffffReserved for future expansion of DMA mapping region.
fee00000feffffffMapping of PCI I/O space. これは、vmalloc空間の静的マッピングです。
VMALLOC_STARTVMALLOC_END-1vmalloc() / ioremap() 空間。 vmalloc(),ioremap()によって返されるメモリは、この領域に動的に配置される。 マシン固有の静的マッピングも、iotable_init()によって、ここに配置される。
VMALLOC_STARTは、high_memory変数の値に基づいて得られる。VMALLOC_ENDは0xff000000である(ヘッダで定義)。
PAGE_OFFSEThigh_memory-1Kernel direct-mapped RAM region. これは、プラットフォームのRAM、通常は、1:1の関係にあるすべてのプラットフォームのRAMを配置します。
CONFIG_PAGE_OFFSETで設定する。一般的な32bit kernelでは 0xC0000000(kernel:user=1GB:3GB設定)となっている。
PKMAP_BASEPAGE_OFFSET-1永続的なkernelマッピング。 カーネル空間にHIGHMEMページを配置する方法の一つ。
MODULES_VADDRMODULES_END-1Kernel module space.
insmodにより挿入されるKernel modulesは、ここに動的に配置されます。
00001000TASK_SIZE-1User space mappings.
スレッド毎のマッピングは、mmap()システムコールにより、ここに配置される。
0000000000000fffCPU vector page / null pointer trap.
ヴェクタremapをサポートしていないCPUは、ヴェクタページをここに配置します。 kernel空間・user空間の双方から、NULLポインタデリファレンスもまた、この配置から捕まえられます。

Please note that mappings which collide with the above areas may result in a non-bootable kernel,
or may cause the kernel to (eventually) panic at run time.
上記領域と衝突するマッピングは、非ブートカーネルになったり、実行時に(最終的に)kernel panic要因となるかもしれないことに、ご注意ください。
Since future CPUs may impact the kernel mapping layout,
user programs must not access any memory which is not mapped inside their 0x0001000 to TASK_SIZE address range.
If they wish to access these areas,
they must set up their own mappings using open() and mmap().
将来のCPUでは、kernelマッピングレイアウトに影響があるかもしれないので、ユーザプログラムは、0x0001000からTASK_SIZEまでのアドレス範囲から外れたメモリをアクセスしてはならない。
もしそれらの領域をアクセスしたければ、open()やmmap()を使って、固有のマッピングをセットアップしなければならない。


関連ファイル

FILE: arch/arm/include/asm/fixmap.h

めも

更新されていないのか、vendorの仕様か、ちょっと配置が違う気がする。
変数を書き換えれば、上の方(vmalloc前後)は任意に動くから、いじってるかもなぁ。

[RCU]rcu.txt

FILE: kernel-*/Documentation/RCU/rcu.txt
kernel-3.2.26

コード見たり、関連単語の理解が浅いので、意味を消化できずに書いています。
反芻して理解するヒトなので、ざっと流しておきます。

RCU Concepts

The basic idea behind RCU (read-copy update) is to split destructiveoperations into two parts, one that prevents anyone from seeing the dataitem being destroyed, and one that actually carries out the destruction.
RCU(read-copy update)の背後にある基本的な考え方は、破壊的な操作を2つに分けることである。
1つは破壊されるデータ要素を参照している側から、誰からも防ぐもの。
もうひとつは実際に破壊を行うもの。

A "grace period" must elapse between the two parts, and this grace periodmust be long enough that any readers accessing the item being deleted havesince dropped their references.
"grace period"(猶予期間)は、2つの部分で経過するべきであり、
この猶予期間は、破壊される要素にアクセスするどんな読み手も、参照先をなくしきるまでは、十分に長くなければならない。

For example, an RCU-protected deletionfrom a linked list would first remove the item from the list, wait fora grace period to elapse, then free the element.
たとえば、RCU-protectedなlinked-listから削除することは、最初にリストから要素を削除し、
猶予期間を待って、その後に、その要素を解放する。
See the listRCU.txt file for more information on using RCU with linked lists.
linked listでRCUを使うより多くの情報は、"listRCU.txt"ファイルを参照ください。

Frequently Asked Questions
よくある質問:
  • Why would anyone want to use RCU?\なぜRCUを使いたがるの?\The advantage of RCU's two-part approach is that RCU readers need not acquire any locks, perform any atomic instructions, write to shared memory, or (on CPUs other than Alpha) execute any memory barriers.\RCUの2つの部分に分けるアプローチの利点は、以下のとおりです。
    • RCUの読み手は、任意のロックを取得する必要が無い
    • RCUの読み手は、どんなアトミック操作も実行できる
    • RCUの読み手は、共有メモリへの書き込みができる
    • (Alphaを除いて)どんなメモリバリアの実行ができる
The fact that these operations are quite expensive on modern CPUs is what gives RCU its performance advantages in read-mostly situations.\これらの操作は、昨今のCPUでは非常にコストが高いという要因で、RCUは読み出しが多い状況下で、その性能を発揮します。\The fact that RCU readers need not acquire locks can also greatly simplify deadlock-avoidance code. \RCUの読み手はロックを取得する必要がないという要因で、非常にシンプルにデッドロックを除外するコードです。
  • How can the updater tell when a grace period has completed if the RCU readers give no indication when they are done? \RCUの読み手が、読み終わった時になにも通知しないなら、猶予期間が完了した時、更新者(updater)は、どのように伝えることができますか。\Just as with spinlocks, RCU readers are not permitted to block, switch to user-mode execution, or enter the idle loop.\spinlockたちのように、RCUの読み手はブロック・ユーザモードへのスイッチ、アイドルループへの遷移を許可されません。\Therefore, as soon as a CPU is seen passing through any of these three states, we know that that CPU has exited any previous RCU read-side critical sections. \したがって、CPUがこれら3つの状態のいずれかへ遷移するとともに、我々は、そのCPUが、前の読み出し側のクリティカルセクションを完了したことを知ることができる。\So, if we remove an item from a linked list, and then wait until all CPUs have switched context, executed in user mode, or executed in the idle loop, we can safely free up that item. \もし我々がlinked listから要素を削除するならば、すべてのCPUが、コンテキストを切り替え終わるか、ユーザモードを実行するか、アイドルループを実行するのを待ち、その要素を安全に解放することができます。\Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the same effect, but require that the readers manipulate CPU-local counters. \RCUのpreemptible 亜種(CONFIG_TREE_PREEMPT_RCU)は、同じ効果を得ますが、読み手にCPUローカルカウンタの操作を要求します。\These counters allow limited types of blocking within RCU read-side critical sections. \これらのカウンタは、RCUの読み手のクリティカルセクション中をブロッキングするための限定的なタイプです。\SRCU also uses CPU-local counters, and permits general blocking within RCU read-side critical sections. \SRCUもまた、CPUローカルカウンタを用い、RCUの読み出し側クリティカルセクション中の一般的なブロッキングを許容します。\These two variants of RCU detect grace periods by sampling these counters. \これら2つのRCUの変種は、これらのカウンタを参照することで、猶予期間を検出します。
  • If I am running on a uniprocessor kernel, which can only do one thing at a time, why should I wait for a grace period?\単一プロセッサkernel上で走行しているなら、同時に1つのことしかできない。何故猶予期間待たないといけないのか。\See the UP.txt file in this directory.\"UP.txt"を参照してください。
  • How can I see where RCU is currently used in the Linux kernel?\現在、Linux kernel内のどこで使われているか見る方法はありますか?\Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu","rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh","srcu_read_lock", "srcu_read_unlock", "synchronize_rcu","synchronize_net", "synchronize_srcu", and the other RCUprimitives.Or grab one of the cscope databases from:\http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html\以下をさがしてみてください。ほかにRCU primitiveも。
    • rcu_read_lock
    • rcu_read_unlockcall_rcu
    • rcu_read_lock_bh
    • rcu_read_unlock_bh
    • call_rcu_bh
    • srcu_read_lock
    • srcu_read_unlock
    • synchronize_rcu
    • synchronize_net
    • synchronize_srcu
  • What guidelines should I follow when writing code that uses RCU?\RCUを使うようなコードを書くとき、どのガイドラインに従えばいいのですか?\See the checklist.txt file in this directory.\このディレクトリにある、checklist.txtファイルを見てください。
  • Why the name "RCU"?\なぜRCUって名前なの?\"RCU" stands for "read-copy update". The file listRCU.txt has more information on where this name came from, search for "read-copy update" to find it.\RCUは、"read-copy update"に基づきます。ファイル"listRCU.txt"に、この名前の由来より詳しい情報があります。"read-copy update"で探せば、それは見つかります。
  • I hear that RCU is patented? What is with that?\RCUは特許済みと聞いた。これについては?\Yes, it is. There are several known patents related to RCU, search for the string "Patent" in RTFP.txt to find them.\はいそうです。RCUに関するいくつかの既知の特許があります。"RTFP.txt"で"Patent"文字列を探すと見つかります。\Of these, one was allowed to lapse by the assignee, and the others have been contributed to the Linux kernel under GPL.\これらのうち、一方は譲受人によって失効させたものと、GPLの下でLinuxカーネルに貢献してきた。\There are now also LGPL implementations of user-level RCU available (http://lttng.org/?q=node/18).\今は、ユーザレベルのLGPL実装もあります(http://lttng.org/?q=node/18)。
  • I hear that RCU needs work in order to support realtime kernels?\RCUは、RT-kernelをサポートするために、必要だと聞いたのだけど?\This work is largely completed.Realtime-friendly RCU can be enabled via the CONFIG_TREE_PREEMPT_RCU kernel configuration parameter.\このworkは概ね完璧です。RT-friendlyなRCUは、kernel config.の"CONFIG_TREE_PREEMPT_RCU"で有効にすることができます。\However, work is in progress for enabling priority boosting of preempted RCU read-side critical sections. This is needed if you have CPU-bound realtime threads.\しかし、workはプリエンプト読み出し側のクリティカルセクションのpriority-boostingを可能にするために作業中です。これは、CPU-boundなRT-threadを持っていれば、必要です。
  • Where can I find more information on RCU?\もっと多くのRCUの情報はどこで見つけられますか?\See the RTFP.txt file in this directory. Or point your browser at http://www.rdrop.com/users/paulmck/RCU/.\ このディレクトリの"RTFP.txt"ファイルを見てください。または、http://www.rdrop.com/users/paulmck/RCU/ を見てください。
  • What are all these files in this directory?\このディレクトリ内のすべてのファイルはなんですの?\See 00-INDEX for the list.\リストは"00-INDEX"を見てね。

[RCU]stallwarn.txt

FILE: kernel-*/Documentation/RCU/stallwarn.txt
kernel-3.2.26, 3.2.8

Using RCU's CPU Stall Detector

The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall detector, which detects conditions that unduly delay RCU grace periods.
rcu_cpu_stall_suppressモジュールパラメータは、RCUのCPUストール検出が可能になります。
ここでいうストールとは、過度にRCUの猶予期間が遅延する状態を検出することです。

This module parameter enables CPU stall detection by default, but may be overridden via boot-time parameter or at runtime via sysfs.
このmodule parameterは、デフォルトでCPUストール検出を有効にしますが、boot時のparmeterもしくはsysfs経由でruntimeに上書きすることができます。

The stall detector's idea of what constitutes "unduly delayed" is controlled by a set of kernel configuration variables and cpp macros
"過度な遅延"を構成するストール検出器のアイデアは、カーネルの設定変数とCPPマクロのセットによって制御されます。
  • CONFIG_RCU_CPU_STALL_TIMEOUT
    This kernel configuration parameter defines the period of time that RCU will wait from the beginning of a grace period until it issues an RCU CPU stall warning. This time period is normally ten seconds.
    このカーネル設定変数は、RCUが、猶予期間のはじめから、"RCU CPU stall"警告を発行するまでの待ち期間を定義します。この期間は、通常10秒です。
  • RCU_SECONDS_TILL_STALL_RECHECK
    This macro defines the period of time that RCU will wait after issuing a stall warning until it issues another stall warning for the same stall.This time period is normally set to three times the check interval plus thirty seconds.
    このマクロは、RCUが"stall warning"を発行した後、別要因で同じstallのstall warningを発行するまでの期間を定義します。この期間は、通常チェック周期の3倍+30秒にセットされます。
  • RCU_STALL_RAT_DELAY
    The CPU stall detector tries to make the offending CPU print its own warnings, as this often gives better-quality stack traces.However, if the offending CPU does not detect its own stall in the number of jiffies specified by RCU_STALL_RAT_DELAY, then some other CPU will complain.This delay is normally set to two jiffies.
    CPU stall検出器は、よりよい品質のスタックトレースを与えるために、問題のCPUは独自の警告を出力しようとします。しかし、問題のCPUが RCU_STALL_RAT_DELAYで与えられるjiffies単位の間に、自身のストールを検出できない場合、他のCPUが出力します。この遅延は、通常 2jiffiesになります。
When a CPU detects that it is stalling, it will print a message similar to the following
CPUがストールを検出するとき、以下のようなメッセージを出力します。
INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)
This message indicates that CPU 5 detected that it was causing a stall, and that the stall was affecting RCU-sched.
このメッセージは、CPU5が、ストールの原因であることを検出したことを示しています。そして、ストールは、RCH-schedに影響を及ぼすことを示しています。
This message will normally be followed by a stack dump of the offending CPU.
このメッセージは、通常、問題のCPUのスタックダンプが続きます。
On TREE_RCU kernel builds, RCU and RCU-sched are implemented by the same underlying mechanism,while on TREE_PREEMPT_RCU kernel builds, RCU is instead implemented by rcu_preempt_state.
TREE_RCU kernel buildに於いて、RCUとRCU-scedは同じ基本的なメカニズムで実装されています。TREE_PREEMPT_RCU kernel buildに於いては、RCUは代わりに、rcu_preempt_stateによって実装されます。
On the other hand, if the offending CPU fails to print out a stall-warning message quickly enough,some other CPU will print a message similar to the following
言い換えれば、問題のあるCPUがstall-警告メッセージを十分に早く出力することに失敗するならば、他のCPUが以下のように出力する:
INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies)
This message indicates that CPU 2 detected that CPUs 3 and 5 were both causing stalls,and that the stall was affecting RCU-bh.
このメッセージは、CPU2が、CPU3と5の両方がstall要因であることを検出したこと、および、RCH-bhへ影響を与えたことを示しています。

This message will normally be followed by stack dumps for each CPU.
このメッセージは、通常、各CPUのスタックダンプが続きます。

Please note that TREE_PREEMPT_RCU builds can be stalled by tasks as well as by CPUs,and that the tasks will be indicated by PID, for example, "P3421".
TREE_PREEMPT_RCU buildでは、CPUのようにタスクによってstallすることができることに注意してください。また、タスクはPIDによって示されます。例えば"P3421"といった具合です。

It is even possible for a rcu_preempt_state stall to be caused by both CPUs -and- tasks,in which case the offending CPUs and tasks will all be called out in the list.
rcu_preempt_stateのstallも、CPUやタスクを起因として起こりえます。この場合、問題のCPUとタスクは、すべてのリストで呼び出されます。

Finally, if the grace period ends just as the stall warning starts printing, there will be a spurious stall-warning message
最後に、stall警告が出力されはじめるのと同時に、猶予期間が終わったならば、誤ったstall警告メッセージがあるだろう。
INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
This is rare, but does happen from time to time in real life.
これはレアだけれども、実生活に於いて随時現れます。

So your kernel printed an RCU CPU stall warning.The next question is "What caused it?" The following problems can result in RCU CPU stall warnings
なので、kernelがRCU CPU stall warningを出力します。次の質問は、"なにがそれを引き起こしたか?"です。以下の問題がRCU CPU stall warningになることがあります。
  • A CPU looping in an RCU read-side critical section.\CPUが、RCUの読み込み側クリティカルセクション内をループしている。
  • A CPU looping with interrupts disabled. This condition can result in RCU-sched and RCU-bh stalls.\CPUが、割り込み禁止状態でループしている。この状態は、RCU-sched stall と RCU-bh stallにつながる。
  • A CPU looping with preemption disabled. This condition can result in RCU-sched stalls and, if ksoftirqd is in use, RCU-bh stalls.\CPUが、preemption無効でループしている。この状態はRCU-sched stallになる。そして、ksoftirqdを使用しているならば、RCU-bh stallになる。
  • A CPU looping with bottom halves disabled. This condition can result in RCU-sched and RCU-bh stalls.\CPUが、bottom halfを無効にしてループしている。この状態は、RCU-sched stall と RCU-bh stallにつながる。
  • For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel without invoking schedule().\CONFIG_PREEMPTを無効にしたカーネルに於いて、kernel内で、schedule()関数を呼び出していないところをループしている。
  • A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might happen to preempt a low-priority task in the middle of an RCU read-side critical section.CONFIG_PREEMPTが有効になったkernelに於いて、RCU読み出し側のクリティカルセクションの途中で、優先度の低いタスクをpreemptするために起こる可能性があるCPU-boundリアルタイムタスク。\※訳注※\この意味理解しないと。。。RealTime TaskがRCU critical sectionを強奪できる? Dispatch禁止も効かない??[color:#808000:This is especially damaging if that low-priority task is not permitted to run on any other CPU,in which case the next RCU grace period can never complete,which will eventually cause the system to run out of memory and hang.While the system is in the process of running itself out of you, memory might see stall-warning messages.\これは、優先度の低いタスクが他のCPUで実行することが許可されいない場合、特にダメージを受ける。その場合には、次のRCU猶予期間は、最終的には、システムのメモリが不足してハングアップする原因となり、これが完了できません。-A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that is running at a higher priority than the RCU softirq threads.This will prevent RCU callbacks from ever being invoked, and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent RCU grace periods from ever completing.Either way, the system will eventually run out of memory and hang.In the CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning messages.\CONFIG_PREEMPTが有効になったkernelに於いて、RCU softirq threadよりも高い優先度で実行しているCPU-boundリアルタイムタスク。
  • A bug in the RCU implementation.\RCU実装の不具合
  • A hardware failure. This is quite unlikely, but has occurred at least once in real life.A CPU failed in a running system, becoming unresponsive, but not causing an immediate crash.This resulted in a series of RCU CPU stall warnings, eventually leading the realization that the CPU had failed.\ハードウェア不良。これは非常に考えにくいが、実生活に於いて少なくとも一度は発生しました。CPUが応答しなくなって、実行中のシステムで失敗したが、即時のクラッシュをひきおこしていない。これは、最終的にはCPUが失敗したという認識をリードし、RCP CPUストールの警告シリーズとなる。
The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
SRCU does not have its own CPU stall warnings,but its calls to synchronize_sched() will result in RCU-sched detectingRCU-sched-related CPU stalls.
Please note that RCU only detects CPU stalls when there is a grace period in progress.
No grace period, no CPU stall warnings.

To diagnose the cause of the stall, inspect the stack traces.
The offending function will usually be near the top of the stack.
If you have a series of stall warnings from a single extended stall, comparing the stack traces can often help determine where the stallis occurring, which will usually be in the function nearest the top of that portion of the stack which remains the same from trace to trace.
If you can reliably trigger the stall, ftrace can be quite helpful.


RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.

doc/RCU

00-INDEX

FILE: Documentation/RCU/00-INDEX
00-INDEXThis file
arrayRCU.txtUsing RCU to Protect Read-Mostly Arrays
checklist.txtReview Checklist for RCU Patches
listRCU.txtUsing RCU to Protect Read-Mostly Linked Lists
lockdep.txtRCU and lockdep checking
NMI-RCU.txtUsing RCU to Protect Dynamic NMI Handlers
rcubarrier.txtRCU and Unloadable Modules
rculist_nulls.txtRCU list primitives for use with SLAB_DESTROY_BY_RCU
rcuref.txtReference-count design for elements of lists/arrays protected by RCU
rcu.txtRCU Concepts
RTFP.txtList of RCU papers (bibliography) going back to 1980.
stallwarn.txtRCU CPU stall warnings (module parameter rcu_cpu_stall_suppress)
torture.txtRCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
trace.txtCONFIG_RCU_TRACE debugfs files and formats
UP.txtRCU on Uniprocessor Systems
whatisRCU.txtWhat is RCU?