1ee65728eSMike Rapoport========= 2ee65728eSMike RapoportActive MM 3ee65728eSMike Rapoport========= 4ee65728eSMike Rapoport 5*88e3009bSNicholas PigginNote, the mm_count refcount may no longer include the "lazy" users 6*88e3009bSNicholas Piggin(running tasks with ->active_mm == mm && ->mm == NULL) on kernels 7*88e3009bSNicholas Pigginwith CONFIG_MMU_LAZY_TLB_REFCOUNT=n. Taking and releasing these lazy 8*88e3009bSNicholas Pigginreferences must be done with mmgrab_lazy_tlb() and mmdrop_lazy_tlb() 9*88e3009bSNicholas Pigginhelpers, which abstract this config option. 10*88e3009bSNicholas Piggin 11ee65728eSMike Rapoport:: 12ee65728eSMike Rapoport 13ee65728eSMike Rapoport List: linux-kernel 14ee65728eSMike Rapoport Subject: Re: active_mm 15ee65728eSMike Rapoport From: Linus Torvalds <torvalds () transmeta ! com> 16ee65728eSMike Rapoport Date: 1999-07-30 21:36:24 17ee65728eSMike Rapoport 18ee65728eSMike Rapoport Cc'd to linux-kernel, because I don't write explanations all that often, 19ee65728eSMike Rapoport and when I do I feel better about more people reading them. 20ee65728eSMike Rapoport 21ee65728eSMike Rapoport On Fri, 30 Jul 1999, David Mosberger wrote: 22ee65728eSMike Rapoport > 23ee65728eSMike Rapoport > Is there a brief description someplace on how "mm" vs. "active_mm" in 24ee65728eSMike Rapoport > the task_struct are supposed to be used? (My apologies if this was 25ee65728eSMike Rapoport > discussed on the mailing lists---I just returned from vacation and 26ee65728eSMike Rapoport > wasn't able to follow linux-kernel for a while). 27ee65728eSMike Rapoport 28ee65728eSMike Rapoport Basically, the new setup is: 29ee65728eSMike Rapoport 30ee65728eSMike Rapoport - we have "real address spaces" and "anonymous address spaces". The 31ee65728eSMike Rapoport difference is that an anonymous address space doesn't care about the 32ee65728eSMike Rapoport user-level page tables at all, so when we do a context switch into an 33ee65728eSMike Rapoport anonymous address space we just leave the previous address space 34ee65728eSMike Rapoport active. 35ee65728eSMike Rapoport 36ee65728eSMike Rapoport The obvious use for a "anonymous address space" is any thread that 37ee65728eSMike Rapoport doesn't need any user mappings - all kernel threads basically fall into 38ee65728eSMike Rapoport this category, but even "real" threads can temporarily say that for 39ee65728eSMike Rapoport some amount of time they are not going to be interested in user space, 40ee65728eSMike Rapoport and that the scheduler might as well try to avoid wasting time on 41ee65728eSMike Rapoport switching the VM state around. Currently only the old-style bdflush 42ee65728eSMike Rapoport sync does that. 43ee65728eSMike Rapoport 44ee65728eSMike Rapoport - "tsk->mm" points to the "real address space". For an anonymous process, 45ee65728eSMike Rapoport tsk->mm will be NULL, for the logical reason that an anonymous process 46ee65728eSMike Rapoport really doesn't _have_ a real address space at all. 47ee65728eSMike Rapoport 48ee65728eSMike Rapoport - however, we obviously need to keep track of which address space we 49ee65728eSMike Rapoport "stole" for such an anonymous user. For that, we have "tsk->active_mm", 50ee65728eSMike Rapoport which shows what the currently active address space is. 51ee65728eSMike Rapoport 52ee65728eSMike Rapoport The rule is that for a process with a real address space (ie tsk->mm is 53ee65728eSMike Rapoport non-NULL) the active_mm obviously always has to be the same as the real 54ee65728eSMike Rapoport one. 55ee65728eSMike Rapoport 56ee65728eSMike Rapoport For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the 57ee65728eSMike Rapoport "borrowed" mm while the anonymous process is running. When the 58ee65728eSMike Rapoport anonymous process gets scheduled away, the borrowed address space is 59ee65728eSMike Rapoport returned and cleared. 60ee65728eSMike Rapoport 61ee65728eSMike Rapoport To support all that, the "struct mm_struct" now has two counters: a 62ee65728eSMike Rapoport "mm_users" counter that is how many "real address space users" there are, 63ee65728eSMike Rapoport and a "mm_count" counter that is the number of "lazy" users (ie anonymous 64ee65728eSMike Rapoport users) plus one if there are any real users. 65ee65728eSMike Rapoport 66ee65728eSMike Rapoport Usually there is at least one real user, but it could be that the real 67ee65728eSMike Rapoport user exited on another CPU while a lazy user was still active, so you do 68ee65728eSMike Rapoport actually get cases where you have a address space that is _only_ used by 69ee65728eSMike Rapoport lazy users. That is often a short-lived state, because once that thread 70ee65728eSMike Rapoport gets scheduled away in favour of a real thread, the "zombie" mm gets 71ee65728eSMike Rapoport released because "mm_count" becomes zero. 72ee65728eSMike Rapoport 73ee65728eSMike Rapoport Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any 74ee65728eSMike Rapoport more. "init_mm" should be considered just a "lazy context when no other 75ee65728eSMike Rapoport context is available", and in fact it is mainly used just at bootup when 76ee65728eSMike Rapoport no real VM has yet been created. So code that used to check 77ee65728eSMike Rapoport 78ee65728eSMike Rapoport if (current->mm == &init_mm) 79ee65728eSMike Rapoport 80ee65728eSMike Rapoport should generally just do 81ee65728eSMike Rapoport 82ee65728eSMike Rapoport if (!current->mm) 83ee65728eSMike Rapoport 84ee65728eSMike Rapoport instead (which makes more sense anyway - the test is basically one of "do 85ee65728eSMike Rapoport we have a user context", and is generally done by the page fault handler 86ee65728eSMike Rapoport and things like that). 87ee65728eSMike Rapoport 88ee65728eSMike Rapoport Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago, 89ee65728eSMike Rapoport because it slightly changes the interfaces to accommodate the alpha (who 90ee65728eSMike Rapoport would have thought it, but the alpha actually ends up having one of the 91ee65728eSMike Rapoport ugliest context switch codes - unlike the other architectures where the MM 92ee65728eSMike Rapoport and register state is separate, the alpha PALcode joins the two, and you 93ee65728eSMike Rapoport need to switch both together). 94ee65728eSMike Rapoport 95ee65728eSMike Rapoport (From http://marc.info/?l=linux-kernel&m=93337278602211&w=2) 96