Hello Priyaranjan, On Mon, Jul 6, 2015 at 1:13 PM, priyaranjan <priyaranjan45678@xxxxxxxxx> wrote: > On Wed, Jul 01, 2015 at 01:58:30PM +0530, priyaranjan wrote: >> Hi Arun, >> >> >> >On Thu, Jun 25, 2015 at 2:33 PM, Arun KS <getarunks@xxxxxxxxx> wrote: >> >Hello Mudongliang, >> > >> > >> > >On Tue, Jun 23, 2015 at 9:01 AM, 慕冬亮 <mudongliangabcd@xxxxxxxxx> wrote: >> > >> >> > >> I know there are rarely float-point operations! What's the exception? >> > > In the linux kernel, how does it handle the float-point operations in >> > the >userland? >> > >> > >>Most of the userspace programs do not use FP instructions. So by >> > >>default floating point engine is turned off during a context switch. >> > >>When a process executes floating point instruction, an undefined >> > >>exception is generated. Exception handler enables the floating point >> > >>engine and jump back to the same instruction which caused the >> > >>exception so that it will get re executed with FP engine on. >> > >> > Is this somehow related to the platform in which linux runs? If the FP >> > operations are valid, then will that still generate the exception or it >> > does a context switch, turns on FP engine and re-executed? Usually kernel code never uses FP instructions. In case if kernel uses FP, it has to save and restore the FP registers. FP engine is turned off when a process starts to execute. When a process encounters FP instruction for the first time, it results in an undefined exception(because FP engine is off). Now the control jumps into kernel undefined exception handler. Here kernel check the op-code which resulted in undefined exception. Why? Because kernel need to verify that it is a co processsor instruction or is it really an undefined instruction. In the later case, kernel kills the task. In the former case, the kernel enables the corresponding co processor(in our case FP engine) and jumps back to user space and re-execute the same instruction(this time with co processor turned on). From now on all the FP instruction will not result in undef exception. Now when kernel decides to move this task away from cpu, it saves the FP registers in thread_info of that corresponding task and disables the FP engine. The explained scenario is for SMP kernel where same task can migrate to different cpus. For single cpu systems, FP register saving is done in lazy manner. This is how ARM handles the FP instructions. I think other architectures also does it in similar manner. Thanks, Arun >> > > >>Hi Priyaranjan, > >>Your email got mangled. Please don't send HTML attachments in your >emails to >>the Linux Kernel mailing lists. > >>Try again to reply to Arun. > >>Thanks, >>Luis > > Sent in plain text format _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
