All of lore.kernel.org
 help / color / mirror / Atom feed
From: sreejith.mm@gmail.com (Sreejith M M)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Question about switch_mm function
Date: Wed, 25 Mar 2015 21:35:22 +0530	[thread overview]
Message-ID: <CAEDT3uTOUtS6jfpDQ+jpw-WABPBSk7f-nWEVQ5Eyaq=63o+7cg@mail.gmail.com> (raw)
In-Reply-To: <CAAYFAvp9NoB422aeD0d-J-c-u-uvAyG6AYq8sZ6_F8S1GUo47Q@mail.gmail.com>

On Wed, Mar 25, 2015 at 9:30 PM, Rajat Sharma <fs.rajat@gmail.com> wrote:
>
> On Mar 25, 2015 6:33 AM, "Sreejith M M" <sreejith.mm@gmail.com> wrote:
>>
>>
>>
>> On Wed, Jan 28, 2015 at 9:56 PM, Sreejith M M <sreejith.mm@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I was trying to understand the difference in scheduling between
>>> processes and threads(belong to same process).
>>>
>>> I was thinking that, when kernel has to switch to a task which belong
>>> to the same process, it does not have to clear / replace page global
>>> directories and other memory related information.
>>>
>>> But in switch_mm function some code is put under CONFIG_SMP function.
>>> What is its signigicance? Code is
>>>
>>> below(http://lxr.free-electrons.com/source/arch/x86/include/asm/mmu_context.h#L37)
>>> .
>>> What I infer is that the code is doing flush tlb, reload page table
>>> directories etc in multiprocessor mode(obviously)  but I believe this
>>> code may never be executed .
>>>
>>> Can anyone help to understand what this part of the function supposed to
>>> do?
>>>
>>>  60 #ifdef CONFIG_SMP
>>>  61           else {
>>>  62                 this_cpu_write(cpu_tlbstate.state, TLBSTATE_OK);
>>>  63                 BUG_ON(this_cpu_read(cpu_tlbstate.active_mm) !=
>>> next);
>>>  64
>>>  65                 if (!cpumask_test_cpu(cpu, mm_cpumask(next))) {
>>>  66                         /*
>>>  67                          * On established mms, the mm_cpumask is
>>> only changed
>>>  68                          * from irq context, from
>>> ptep_clear_flush() while in
>>>  69                          * lazy tlb mode, and here. Irqs are blocked
>>> during
>>>  70                          * schedule, protecting us from
>>> simultaneous changes.
>>>  71                          */
>>>  72                         cpumask_set_cpu(cpu, mm_cpumask(next));
>>>  73                         /*
>>>  74                          * We were in lazy tlb mode and leave_mm
>>> disabled
>>>  75                          * tlb flush IPI delivery. We must reload CR3
>>>  76                          * to make sure to use no freed page tables.
>>>  77                          */
>>>  78                         load_cr3(next->pgd);
>>>  79                         trace_tlb_flush(TLB_FLUSH_ON_TASK_SWITCH,
>>> TLB_FLUSH_ALL);
>>>  80                         load_LDT_nolock(&next->context);
>>>  81                 }
>>>  82         }
>>>  83 #endif
>>>
>>>
>>> --
>>> Regards,
>>> Sreejith
>>
>>
>> Hi ,
>>
>> can someone please give me any answers for this?
>>
>> --
>> Regards,
>> Sreejith
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
> This code is handling context switch from a kernel thread back to user mode
> thread so TLB entries are invalid translation for user mode thread and do
> not correspond to user process pgd. It is Master kernel page table
> translation as a result of kernel thread execution.
>
> -Rajat
Hi Rajat,

If that is the case, why this code is put under CONFIG_SMP switch?


-- 
Regards,
Sreejith

  reply	other threads:[~2015-03-25 16:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 16:26 Question about switch_mm function Sreejith M M
2015-03-25 13:30 ` Sreejith M M
2015-03-25 16:00   ` Rajat Sharma
2015-03-25 16:05     ` Sreejith M M [this message]
2015-03-25 17:25       ` Valdis.Kletnieks at vt.edu
2015-03-25 17:31         ` Sreejith M M
2015-03-25 17:33           ` Rajat Sharma
2015-03-25 19:13             ` Rajat Sharma
2015-03-25 19:25               ` Valdis.Kletnieks at vt.edu
2015-03-25 19:39                 ` Rajat Sharma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEDT3uTOUtS6jfpDQ+jpw-WABPBSk7f-nWEVQ5Eyaq=63o+7cg@mail.gmail.com' \
    --to=sreejith.mm@gmail.com \
    --cc=kernelnewbies@lists.kernelnewbies.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.