<br><br><div class="gmail_quote">On Sat, Feb 9, 2013 at 8:08 AM, Peter Teoh <span dir="ltr"><<a href="mailto:htmldeveloper@gmail.com" target="_blank">htmldeveloper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Sat, Feb 9, 2013 at 1:08 AM, Gaurav Jain <span dir="ltr"><<a href="mailto:gjainroorkee@gmail.com" target="_blank">gjainroorkee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">What happens if the kernel executing in some process context (let's say executing a time-consuming syscall) gets interrupted by the Timer - which is apparently allowed in 2.6 onwards kernels.<div><br></div>
<div>My understanding is that once the interrupt handler is done executing, we should switch back to where the kernel code was executing. Specifically, the interrupt handler for the Timer interrupt should not schedule some other task since that might leave kernel data in an inconsistent state - kernel didn't finish doing whatever it was doing when interrupted. </div>
</div></blockquote><div><br></div></div><div>at the microscopic level, every stream of assembly instructions can always be broken up and intercepted by interrupt, and possibly switched into another stream of assembly instruction or logic, the maintenance of state "consistency" is done via context switching.</div>
</div></blockquote><div><br></div><div>context switching is done at software level, and i am not if there is difference between process context switch or thread/task level context switching, but hardware only guarantee register context switch - and not sure if it covers all the floating point (SSE) registers too (unlikely, performance overheads)....so.."consistency" is really how you write your software. and u also have multiple switching (by different CPU) all taking place independently all the time, writing into the same piece of RAM.</div>
<div><br></div><div>I also know that nvidia GPU does not clean up its memory/state when switching from one process to another process, but that is beyond the control of hardware switching logic of the CPU anyway.</div><div>
<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">
<div><br></div><div>So, does the Timer interrupt handler include such a policy for the above case? </div><span><font color="#888888"><div><div><br></div>-- <br><div dir="ltr"><font face="arial, helvetica, sans-serif">Gaurav Jain</font><div>
<br></div><div><font face="arial, helvetica, sans-serif"><br><br></font></div></div>
</div></font></span></div>
<br></div>_______________________________________________<br>
Kernelnewbies mailing list<br>
<a href="mailto:Kernelnewbies@kernelnewbies.org" target="_blank">Kernelnewbies@kernelnewbies.org</a><br>
<a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<br></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br>Regards,<br>Peter Teoh
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Regards,<br>Peter Teoh