1

I was trying to understand the difference between a task_struct's mm and active_mm fields, and came across a 20-year old email from Linus Torvalds which references the notion of "anonymous processes":


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

   [...]

 - "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.
3
  • 2
    It's more or less explained in the part of the mail you left out. Kernel threads that only access kernel memory don't care what's in user space memory, so an "anonymous process" is an optimization for these. “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.”
    – cg909
    Mar 22 at 21:29
  • @cg909 Could you post this comment as the answer? Mar 22 at 21:42
  • @AlexBaranowski Done.
    – cg909
    Mar 22 at 23:00
5

It's more or less explained in the part of the email you left out.

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.

Kernel threads only access kernel memory, so they don't care what's in user space memory. "Anonymous process" is an optimization for these.

When the scheduler switches to a kernel thread task it can then skip the relatively time-consuming memory mapping setup and just keep the address space of the previous process in place. The kernel part of the address space is mapped the same way for all processes, so it doesn't make any difference which mapping is used for these tasks.

This optimization could also temporarily be applied to a user space task while that task is running kernel space code, e.g. while waiting for a system call like sync to complete, as the real address space only needs to be restored right before returning back to user space code. As mentioned in the email, it seems like this isn't done anymore at least since bdflush was superseded by the pdflush kernel thread.

1

It denotes Anonymous memory as a memory mapping with no file or device backing it. This is how programs allot memory from the operating system for use by things like the heap and stack. Firstly, an anonymous mapping only allots virtual memory. The new mapping starts with a redundant copy on the write mapping of the zero page.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.