Skip to content

Latest commit

 

History

History
109 lines (81 loc) · 5.26 KB

File metadata and controls

109 lines (81 loc) · 5.26 KB

List: linux-kernel Subject: Re: active_mm
From: Linus Torvalds <torvalds () transmeta ! com> Date: 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.

抄送linux内核,通常我不写内核代码注解,只有当我希望更多的人理解的时候我才这么做了。

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).

有没有使用,task_struct中的,“MM”和“Actuvithmm”的简要描述?

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.

    显然使用“匿名空间”的是那些不需要用户空间映射的线程 - 所有的内核线程 都属于这类,甚至连“真实”的线程偶尔也会说某些时候它们也对用户空间不感兴趣,因此 调度器也尽量避免浪费时间在切换VM状态上。目前只有老旧的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.

    “task->mm” 指向“真实空间"。对于匿名空间,tsk->mm 是 NULL,从逻辑上 来说匿名空间真的根本不应该有个真实的空间。

  • 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->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.

    对于带有真实空间的进程(就是tsk->mm 是非 NULL)来说 active_mm 总是 指向同一个真实空间

    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 == NULL,而且当这个匿名进程在运行时 tsk->active_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.

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.

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).

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)