leandrof/linux
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs/vm: active_mm.txt convert to ReST format

Browse Source 
Just add a label for cross-referencing and indent the text to make it
``literal``

Signed-off-by: Mike Rapoport <rppt@linux.vnet.ibm.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Mike Rapoport 2018-03-21 21:22:17 +02:00 committed by Jonathan Corbet
parent 86afad7d87
commit 438b8e24d1
1 changed files with 73 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
Documentation/vm/active_mm.txt
View File

@ -1,83 +1,91 @@
List: linux-kernel .. _active_mm:
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. Active MM
=========
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: List: linux-kernel
Subject: Re: active_mm
From: Linus Torvalds <torvalds () transmeta ! com>
Date: 1999-07-30 21:36:24
- we have "real address spaces" and "anonymous address spaces". The Cc'd to linux-kernel, because I don't write explanations all that often,
difference is that an anonymous address space doesn't care about the and when I do I feel better about more people reading them.
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 On Fri, 30 Jul 1999, David Mosberger wrote:
doesn't need any user mappings - all kernel threads basically fall into >
this category, but even "real" threads can temporarily say that for > Is there a brief description someplace on how "mm" vs. "active_mm" in
some amount of time they are not going to be interested in user space, > the task_struct are supposed to be used? (My apologies if this was
and that the scheduler might as well try to avoid wasting time on > discussed on the mailing lists---I just returned from vacation and
switching the VM state around. Currently only the old-style bdflush > wasn't able to follow linux-kernel for a while).
sync does that.
- "tsk->mm" points to the "real address space". For an anonymous process, Basically, the new setup is:
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 - we have "real address spaces" and "anonymous address spaces". The
"stole" for such an anonymous user. For that, we have "tsk->active_mm", difference is that an anonymous address space doesn't care about the
which shows what the currently active address space is. 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 rule is that for a process with a real address space (ie tsk->mm is The obvious use for a "anonymous address space" is any thread that
non-NULL) the active_mm obviously always has to be the same as the real doesn't need any user mappings - all kernel threads basically fall into
one. 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.
For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the - "tsk->mm" points to the "real address space". For an anonymous process,
"borrowed" mm while the anonymous process is running. When the tsk->mm will be NULL, for the logical reason that an anonymous process
anonymous process gets scheduled away, the borrowed address space is really doesn't _have_ a real address space at all.
returned and cleared.
To support all that, the "struct mm_struct" now has two counters: a - however, we obviously need to keep track of which address space we
"mm_users" counter that is how many "real address space users" there are, "stole" for such an anonymous user. For that, we have "tsk->active_mm",
and a "mm_count" counter that is the number of "lazy" users (ie anonymous which shows what the currently active address space is.
users) plus one if there are any real users.
Usually there is at least one real user, but it could be that the real The rule is that for a process with a real address space (ie tsk->mm is
user exited on another CPU while a lazy user was still active, so you do non-NULL) the active_mm obviously always has to be the same as the real
actually get cases where you have a address space that is _only_ used by one.
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 For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the
more. "init_mm" should be considered just a "lazy context when no other "borrowed" mm while the anonymous process is running. When the
context is available", and in fact it is mainly used just at bootup when anonymous process gets scheduled away, the borrowed address space is
no real VM has yet been created. So code that used to check returned and cleared.
if (current->mm == &init_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.
should generally just do 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.
if (!current->mm) 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
instead (which makes more sense anyway - the test is basically one of "do if (current->mm == &init_mm)
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, should generally just do
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) 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)