Documentation/vm/active_mm.txt-CSDN博客

Chinese translated version of Documentation/vm/active_mm.txt

If you have any comment or update to the content, please contact the
original document maintainer directly. However, if you have a problem
communicating in English you can also ask the Chinese maintainer for
help. Contact the Chinese maintainer if this translation is outdated
or if there is a problem with the translation.

Chinese maintainer:Luo Yangyang <794436342@qq.com>
---------------------------------------------------------------------
Documentation/vm/active_mm.txt的中文翻译

如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
译存在问题，请联系中文版维护者。

中文版维护者：罗秧秧 <794436342@qq.com>
中文版翻译者：罗秧秧 <794436342@qq.com>
中文版校译者：罗秧秧 <794436342@qq.com>

以下为正文
---------------------------------------------------------------------

List: linux-kernel

Subject: Re: active_mm
From: Linus Torvalds <torvalds () transmeta ! com>
Date: 1999-07-30 21:36:24

列表： linux-kernel（Linux内核）
主题：回复：active_mm
来自： Linus Torvalds <torvalds () transmeta ! com>
日期： 1999-07-30 21:36:24

Cc'd to linux-kernel, because I don't write explanations all that often,
and when I do I feel better about more people reading them.

On Fri, 30 Jul 1999, David Mosberger wrote:
>
> Is there a brief description someplace on how "mm" vs. "active_mm" in
> the task_struct are supposed to be used? (My apologies if this was
> discussed on the mailing lists---I just returned from vacation and
> wasn't able to follow linux-kernel for a while).

抄送给linux-kernel（Linux内核），因为我不经常写解释，
当我写了的时候，我更好地感觉到更多的人会阅读他们。

星期五， 1999年7月30日，David Mosberger写道：
>
>对task_struct中的"mm" 与 "active_mm"
>如何在某个地方被使用有没有一个简要的描述？
>（如果这是在邮件列表中讨论，我道歉---我刚刚度假归来，
>有一段时间没有能够跟随到linux-kernel查看）。

Basically, the new setup is:

- we have "real address spaces" and "anonymous address spaces". The
difference is that an anonymous address space doesn't care about the
user-level page tables at all, so when we do a context switch into an
anonymous address space we just leave the previous address space
active.

总的来说，新的设置是：

- 我们有“真正的地址空间里”和“匿名地址空间”。
不同的是，一个匿名地址空间并不关心
用户级的页表，所以当我们做了一个上下文切换到
匿名地址空间时，我们只是让之前的地址空间保持
有效。

The obvious use for a "anonymous address space" is any thread that
doesn't need any user mappings - all kernel threads basically fall into
this category, but even "real" threads can temporarily say that for
some amount of time they are not going to be interested in user space,
and that the scheduler might as well try to avoid wasting time on
switching the VM state around. Currently only the old-style bdflush
sync does that.

一个“匿名地址空间”的明显用途是任何线程
不需要任何用户映射 - 所有内核线程基本上归于
这一类，但即使“真正的”线程暂且可以说是
它们在用户空间里不关心的一段时间，
这调度还不如尽量避免在切换虚拟机状态上浪费时间。
目前只有旧式的bdflush文件中参数同步这样做。

- "tsk->mm" points to the "real address space". For an anonymous process,
tsk->mm will be NULL, for the logical reason that an anonymous process
really doesn't _have_ a real address space at all.

- however, we obviously need to keep track of which address space we
"stole" for such an anonymous user. For that, we have "tsk->active_mm",
which shows what the currently active address space is.

-“tsk->mm”指向"real address space"（“真正的地址空间”）。对于一个匿名进程
来说，tsk->mm将为NULL（空），逻辑原因是一个匿名进程真正地不再有真正的地址空间。

- 但是，我们显然需要跟踪我们为这样一个匿名用户“偷”来的地址空间。
对于这一点，我们有“ tsk->active_mm”，
这表明当前有效的地址空间是什么。

The rule is that for a process with a real address space (ie tsk->mm is
non-NULL) the active_mm obviously always has to be the same as the real
one.

For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the
"borrowed" mm while the anonymous process is running. When the
anonymous process gets scheduled away, the borrowed address space is
returned and cleared.

该规则是，对于有一个真正地址空间（即TSK->mm为非空）
的进程来说，active_mm显然总是与实际的一样。

对于一个匿名进程来说，tsk->mm== NULL，TSK->active_mm则是
"借的" mm，而匿名进程正在运行。当
匿名进程被安排时，借用的地址空间
被返回和清除。

To support all that, the "struct mm_struct" now has two counters: a
"mm_users" counter that is how many "real address space users" there are,
and a "mm_count" counter that is the number of "lazy" users (ie anonymous
users) plus one if there are any real users.

为了支持这一切，“struct mm_struct”现在有两个计数器：
一个“ mm_users ”计数器是统计有多少“真实地址空间”用户，
“mm_count”计数器是统计如果有任何真正用户情况下“偷懒”用户（即匿名
用户）的数量加1。

Usually there is at least one real user, but it could be that the real
user exited on another CPU while a lazy user was still active, so you do
actually get cases where you have a address space that is _only_ used by
lazy users. That is often a short-lived state, because once that thread
gets scheduled away in favour of a real thread, the "zombie" mm gets
released because "mm_users" becomes zero.

通常至少有一个真正用户，但它可能是，真正
用户在另一个CPU上退出，而一个懒惰用户仍然是有效的，所以
实际情况下，你拥有的是一个只被懒惰用户使用的地址空间。
这往往是一个短暂的状态，因为一旦该线程被调度，
被一个真正线程所支持，“僵尸”mm将得到释放，
因为“mm_users”已变为0。

Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any
more. "init_mm" should be considered just a "lazy context when no other
context is available", and in fact it is mainly used just at bootup when
no real VM has yet been created. So code that used to check

if (current->mm == &init_mm)

should generally just do

if (!current->mm)

instead (which makes more sense anyway - the test is basically one of "do
we have a user context", and is generally done by the page fault handler
and things like that).

此外，新规则是没有人曾经把“init_mm”作为一个真正的MM。
“init_mm”应被视为仅仅是一个“没有其他上下文
可用时的懒惰上下文”，事实上，它主要在尚未建立真正的虚拟机，启动时被使用。
因此，用来测试的代码

if (current->mm == &init_mm)

一般应该由判断

if (!current->mm)

来代替（无论如何这使得有更大的意义 - 测试基本上是“
我们是否有一个用户上下文”，通常是通过页错误处理程序
之类的东西完成的）。

Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago,
because it slightly changes the interfaces to accommodate the alpha (who
would have thought it, but the alpha actually ends up having one of the
ugliest context switch codes - unlike the other architectures where the MM
and register state is separate, the alpha PALcode joins the two, and you
need to switch both together).

(From http://marc.info/?l=linux-kernel&m=93337278602211&w=2)

无论如何，刚才我把pre-patch-2.3.13-1放在ftp.kernel.org上了，
因为为了适应alpha值稍微改变了接口（谁
会想到，但实际上alpha最终成为
最丑陋的上下文切换代码之一 - 不像其他架构中的MM
和寄存器状态是独立的，alpha PALcode连接两个，你
需要一起切换两者）。

（来自http://marc.info/?l=linux-kernel&m=93337278602211&w=2 ）