Documentation/mm/active_mm.rst

Source file repositories/reference/linux-study-clean/Documentation/mm/active_mm.rst

File Facts

System
Linux kernel
Corpus path
Documentation/mm/active_mm.rst
Extension
.rst
Size
4259 bytes
Lines
96
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

=========
Active MM
=========

Note, the mm_count refcount may no longer include the "lazy" users
(running tasks with ->active_mm == mm && ->mm == NULL) on kernels
with CONFIG_MMU_LAZY_TLB_REFCOUNT=n. Taking and releasing these lazy
references must be done with mmgrab_lazy_tlb() and mmdrop_lazy_tlb()
helpers, which abstract this config option.

::

 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.

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

 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.

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

    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.

 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

Annotation

Implementation Notes