<p dir="ltr"><br>
On Mar 25, 2015 10:31 AM, "Sreejith M M" <<a href="mailto:sreejith.mm@gmail.com">sreejith.mm@gmail.com</a>> wrote:<br>
><br>
> On Wed, Mar 25, 2015 at 10:55 PM, <<a href="mailto:Valdis.Kletnieks@vt.edu">Valdis.Kletnieks@vt.edu</a>> wrote:<br>
> > On Wed, 25 Mar 2015 21:35:22 +0530, Sreejith M M said:<br>
> ><br>
> >> > This code is handling context switch from a kernel thread back to user mode<br>
> >> > thread so TLB entries are invalid translation for user mode thread and do<br>
> >> > not correspond to user process pgd. It is Master kernel page table<br>
> >> > translation as a result of kernel thread execution.<br>
> >> ><br>
> >> > -Rajat<br>
> >> Hi Rajat,<br>
> >><br>
> >> If that is the case, why this code is put under CONFIG_SMP switch?<br>
> ><br>
> > Vastly simplified because I'm lazy :)<br>
> ><br>
> > If you look at the code, it's poking the status on *other* CPUs. That's why<br>
> > the cpumask() stuff.<br>
> ><br>
> > If you're on a single execution unit, you don't have to tell the other<br>
> > CPU about the change in state, because there isn't an other CPU.<br>
><br>
> can you come out of this lazy mode explain this a bit more because I<br>
> am a newbie ?or tell me what else I should know before I have to<br>
> understand this code<br>
><br>
> --<br>
> Regards,<br>
> Sreejith</p>
<p dir="ltr">Valdis is talking about lazy tlb flush, not him being lazy. Otherwise he wouldn't have replied at all :)</p>