Question about switch_mm function

[sreejith.mm@gmail.com (Sreejith M M)]

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